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ABSTRACT 

This  technical  report  describee  the  work  accomplished  during  Phesee  I 
end  II  of  Contract  F33615-82-C-5114  from  1  October  1982  to  30  April  1983. 
The  report  contains  conclusions  about  the  feasibility  of  expert  systems  for 
price  analysis,  provides  an  analysis  of  contract  pricing,  discuases  the 
preliminary  design  of  an  intelligent  manual,  and  briefly  surveys  the 
educational  environment  within  the  Air  Force. 

Wd  identify  problema  aaaociated  with  price  analysis  during  procurement 
in  the  Air  Force  and  diaeuas  the  feasibility  of  designing  an  "expert 
systt  "  using  techniques  from  the  field  of  artificial  intelligence.  The 
applicable  areas  of  procurement  are  identified,  and  an  analysis  of  contract 
pricing  is  presented.  An  "intelligent  manual"  type  of  expert  system  can 
impact  base-level  procurement  activity  significantly. 

We  then  present  the  design  of  a  prototype  of  an  intelligent  manual  in  an 
information  base  called  X3SFO*,  discuss  some  of  the  problems  with  this 
design,  and  present  a  proposed  redesign  using  another  information  base 
called  ZOG*.  He  address  issues  related  to  the  education  and  training  of 
price  analysts  and  identify  how  an  expert  system  could  improve  performance 
among  both  untrained  and  trained  personnel.  He  show  how  the  system  could 
integrate  price  analysis  in  the  Air  Force. 

Appendix  1  contains  a  suamary  of  the  interviews  that  were  performed 
along  with  conclusions  from  these  interviews.  Appendix  2  shows  a  buyer 
guided  by  the  XIHFO  version  in  aaking  a  competitive  procurement  decision. 


*This  is  not  an  abbreviation.  The  name  is  intended  to  suggest  that  it  is 
an  extended  information  base. 


hoc  is  not  an  abbreviation  either.  The  name  was  selected  for  its  ease 
of  pronunciation  and  novelty,  and  is  intended  to  suggest  thst  20G  is  a 
novel  system  for  human-computer  interaction. 
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Appendix  3  describes  the  ZOG  system  snd  shows  an  example  of  pricing  in  ZOG 
that  corresponds  to  the  XINTO  example. 
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PREFACE 


Thia  report  is  based  on  interviews  with  instructors  at  the  Air  Force 
Institute  of  Technology  and  with  price  analysts  in  the  Air  Force  Logistics 
Command  and  at  the  Air  Force  Contract  Management  Division.  We  would  like 
to  thank  them  for  their  generous  help.  The  final  opinions  expressed  here 


are  our  own. 


The  KIOTO  system  was  developed  at  the  Massachusetts  Institute  of 
Technology.  The  ZOG  system  was  developed  in  Carnegie*-Mellon  University 
(Dr.  Kamesh  Ramakrishna  was  one  of  the  researchers  involved  in  the  design 
of  ZOG)  —  the  ZOG  project  was  supported  by  the  Office  of  Naval  Research. 

The  versions  of  KIOTO  and  ZOG  used  here  are  in  the  public  domain  and  may  be 
obtained  freely. 
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1.  nmiODDCTIOH 


This  report  concludes  the  first  two  phases  of  our  feasibility  study  on 
designing  an  expert  system  for  the  contract  pricing  task.  We  conclude  that 
it  would  be  possible  to  define  such  a  system.  Given  current  Air  Force 
price  analysis  methods,  an  "intelligent  manual"  approach  will  pay  off  the 
most  in  the  short  term.  The  development  of  an  intelligent  manual  will 
focus  long-term  efforts  for  integrating  different  levels  and  systems  for 
price  analysis. 

We  developed  one  prototype  version  of  an  intelligent  manual  and  are 
developing  a  second  one.  By  the  end  of  the  contract  period,  we  should  have 
an  intelligent  manual  that  covers  a  small  but  significant  part  of  the  price 
analysis  task  at  the  base- level. 


Our  conclusions  may  be  summarized  as  follows: 

1.  The  three  levels  at  which  price  analysis  is  performed  have 
different  inediate  needs  —  in  base  procurement,  the  support 
needed  is  expert  guidance;  in  central  procurement,  the  support 
needed  is  in  computation,  information  pertaining  to  the 
contractor  and  to  the  solicitation,  and  in  focusing  attention  to 
the  relevant  factors;  in  systems  procurement,  the  support  needed 
is  good  human  interfaces  between  users  and  existing  databases 
and  computational  tools. 

2.  Price  Analysis  is  a  multi-level,  hierarchical  task  —  not  all 
price  analysts  function  at  all  these  levels.  The  price  analysis 
system  of  the  future  should  support  all  levels  of  this  task  and 
should  allow  the  use  of  advanced  techniques  even  by  relative 
novices . 

3 .  An  intelligent  manual  is  an  appropriate  support  mechanism  for 
base  procurement.  We  have  examples  of  what  such  a  manual  should 
look  like. 

4.  An  intelligent  manual  will  act  as  a  focus  for  long-term 
development  of  support  mechanisms  for  price  analysis. 

5.  An  intelligent  manual  is  an  appropriate  training  tool  both  for 
initial  education  and  continued  on-the-job  training  of  price 
analysts . 
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2.  EXPERT  SYSTEMS  FOR  PRICE  AHALYSIS:  A  FEASIBILITY  STUDY 

2.1  Introduction 

The  following  chapter  summarizes  the  pricing  environment  within  the  Air 
Force  and  contains  recommendations  for  feasibility.  Price  Analysis  is 
performed  at  many  different  levels  within  Department  of  Defense  procurement 
activities.  At  the  highest  levels,  price  analysis  is  fairly  sophisticated, 
carried  out  by  highly  trained  personnel;  however,  at  lower  levels  this  is 
not  the  case.  This  study  surveys  the  price  analysis  function  at  three 
different  levels  (Systems  Command -Central  Management  Division,  Logistics 
Command-Central  and  Base  procurement)  within  the  Air  Force  in  order  to 
ascertain  the  feasibility  of  designing  "expert  systems”  by  evaluating  the 
following  questions. 

1 .  What  kinds  of  expert  systems  can  be  designed  with  current 
technology  for  buyers  and  price  analysts  at  the  different 
levels? 

2.  What  kind  of  assistance  can  be  or  should  be  provided? 

3.  What  kinds  of.  information,  knowledge,  and  environment  would  have 
to  be  maintained  by  the  Air  Force  to  exploit  expert  systems? 

We  reconssend  that  the  Air  Force  embark  on  a  long-range  program  of 
providing  support  at  all  levels  of  the  procurement  function.  Base-level 
buyers  who  function  without  specialist  assistance  need  the  most  support  in 
the  short-term  (1  to  2  years)  and  we  have  designed  an  instructional  expert 
system  for  this  purpose  (described  in  Chapter  4) .  We  also  recommend  a 
three  to  five  year  program  intended  to  support  central  procurement 
activities,  and  a  five  year  (and  longer)  program  for  extending  the  support 
to  all  levels  of  procurement  in  the  Air  Force. 
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2.2  The  Price  Analysis  Task 

An  intelligent  computer  system  designed  to  aid  in  price  analysis  must 
have  the  capabilities  to  function  within  the  Air  Force  procurement  domain. 
There  are  three  major  functional  groups  involved:  the  customer,  the 
contractor  and  :.,-e  contracting  office.  The  customer  provides  a  technical 
evaluation  of  the  proposals  submitted  and  an  estimate  of  the  proposed 
procurement  costs.  The  contractor  submits  a  proposed  price  for  providing 
the  desired  procurement.  The  contracting  officer  is  responsible  for 
soliciting  proposals,  evaluating  the  proposals,  establishing  a  negotiation 
position,  carrying  out  the  negotiations,  and  consummating  a  contract. 
Throughout  this  process  the  contracting  officer  may  call  specialists  to 
assist  in  the  process.  The  most  general  type  of  intelligent  system  would 
carry  out  all  these  functions  of  the  contracting  officer.  A  less  ambitious 
undertaking  would  concentrate  on  one  or  more  of  the  several  components  of 
the  task.  If  the  latter  course  is  chosen,  one  must  determine  which 
components  of  the  procurement  process  are  amenable  to  automation  in  the 
form  of  an  intelligent  computer  systems. 

Price  analysis  is  the  specialty  function  chosen  for  study.  This 
function  is  defined  as  the  determination  of  a  fair  and  reasonable  price  for 
the  buy.  The  task  may  be  as  simple  as  comparing  two  numbers  and  choosing 
the  smaller  or  as  difficult  as  constructing  a  price  based  on  costs 
generated  from  engineering  specifications.  As  with  the  contracting 
officer,  the  price  analysis  function  has  access  to  other  specialty 
functions.  For  example,  field  personnel  can  provide  information  as  to  the 
level  of  compliance  with  Cost  Accounting  Standards  Board  (CASB)  disclosure 
requirements  and  technical  specialists  can  provide  evaluations  of  proposed 
work  processes  and  material  and  labor  specifications.  The  system  design 
problem  is  choosing  which  of  these  to  include  as  part  of  the  price  analysis 
function  and  which  to  treat  as  specialty  areas  to  be  called  by  the  price 
analysis  system  when  needed. 

The  functions  carried  out  by  a  price  analyst  have  to  do  both  with  an 
analysis  of  the  price  proposed  as  well  as  an  analysis  of  the  costs  of  the 
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item  or  aervice  being  offered.  Ideally,  a  coat  analyaia  ia  undertaken  to 
determine  the  validity  of  the  coat  estimates  of  the  individual  components 
of  a  propoaal.  A  determination  of  the  fairneaa  and  reeaonableneaa  of  the 
price  ahould  use  these  results  as  a  major  input.  Thus,  the  price  analyst 
needs  both  capabilities. 

Price  analysis  is  characterized  by  five  basic  types  of  comparisons  used 
in  evaluating  proposals  (ref:  AFLC  Base  Level  Pricing  Guide,  Regulation 
70-6): 

1.  Competitive  price  quotations 

2.  Catalog,  Market  or  Regulated  prices 

3 .  Prior  quotes  and  prices  for  similar  items 

4.  Cost  estimating  relationships 

5.  Governsent  estimates 


If  cost  analysis  is  to  be  undertaken  the  contractor  must  provide 
adequate  data.  This  data  is  usually  found  on  DD  Form  633.  It  should  be 
noted  that  contractors  are  required  to  file  DD  Form  633  for  buys  of 
$500,000  or  more;  thus,  detailed  contractor  cost  data  is  generally  not 
available  for  buys  of  less  than  this  amount.  The  evaluation  requires  a 
detailed  analysis  of  the  direct  and  allocated  costs  associated  with  the 
proposal.  An  analysis  of  these  costs  and  the  process  used  by  the 
contractor  to  put  together  the  proposal  are  used  to  derive  a  government 


negotiating  position. 


Another  relevant  issue  is  the  differentiation  in  the  price  analysis 
function  among  different  commands  or  types  of  procurement.  For  example, 
what  are  the  similarities  and  differences  between  Air  Force  Systems  Command 
and  Air  Force  Logistics  Command  price  analysis?  Does  base  level  pricing 
have  any  commonalities  with  central  procurement  pricing?  Are  different 
systems  needed  for  the  buying  facilities?  The  following  sections  address 
these  issues  as  they  relate  to  the  feasibility  of  constructing  an  expert 
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price  analysis  system. 

2.3  Characterizing  Price  Analysis  in  the  Air  Force 

We  identified  and  evaluated  three  levels  of  buying  activity  (AF  Systems 
Conmand  central  procurement,  AF  Logistics  Command  central  procurement,  and 
AF  Logistics  Command  base  procurement).  This  evaluation  is  summarized  in 
Table  1  and  is  in  terms  of  the  following: 


-  type  of  analysis  generally  undertaken; 

-  type  of  procurement; 

-  type  of  accounting  systems  encountered; 

-  availability  of  data; 

-  areas  of  possible  assistance. 

Base-Level 


Analysis 


Procurement 

Type 

Accounting 

Systems 


Price 

Analysis 

varied 


Non-standard, 
Poorly  developed 


Data  Availability  very  little 


AFLC 

Cost  &  Price 
Ana lysis 

diverse, 
mostly  Spares 

Uniq ue, 

DCAS  support 

occasionally 


AFSC 

Cost 

Analysis 
Large  Systems 


Sophisticated, 
but  diverse 

lots  of  data 


Table  1:  Summary  characterization  of  Price  Analysis 


.  .  .  .  3 

At  the  AF  Logistics  Command  base  level  pricing  function  price  analysis 

is  undertaken  because  of  the  inability  to  obtain  extensive  data  from  the 
contractor.  The  types  of  procurement  at  the  base  level  are  varied  and 


JBaf erred  to  as  base  level  pricing.  AFLC  is  evaluated  because  of  the 
availability  of  the  command  to  the  research  team.  It  is  recognized  that 
the  pricing  problems  and  the  environment  are  somewhat  different  between 
AFLC  and  other  commands,  but  there  are  many  similarities. 
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include  conscruction  end  engineering  services,  basic  services,  and 
coaeodicies  procurement.  The  types  of  accounting  systems  used  by  the 
contractors  are  poorly  developed,  non-standard,  and  provide  little  price 
analysis  support.  Thus  very  little  data  is  provided  to  the  buyer. 

Both  price  analysis  and  cost  analysis  are  undertaken  by  AFLC  central 
procurement.  There  appears  to  be  a  large  diversity  in  the  site  of 
contracts  handled.  The  major  type  of  activity  is  procurement  of  spares. 
Analysts  are  confronted  with  many  diverse  contractors  having  somewhat 
unique  accounting  systems.  The  data  available  tends  to  be  contractor 
specific  and  is  generally  provided  at  the  discretion  of  the  contractor. 

This  data  is  unlikely  to  be  standardized.  There  is  some  field  support  from 
Defense  Contract  Administration  Services  (DCAS).  Contract  administration 
offices  at  the  contractor's  plant  also  provide  support,  especially  for  the 
larger  contractors. 

The  central  level  procurement  facility  of  the  Systems  Command  is 
primarily  concerned  with  large  dollar  value  buys  from  a  relatively  small 
number  of  contractors.  Cost  analysis  is  the  primary  form  of  analysis.  The 
major  areas  of  procurement  responsibility  are  research,  development  and 
production  of  nav  equipment.  Systems  Command  contracts  primarily  with  25 
defense  contractors.  There  are  government  teams  on  site  at  each  major 
facility  (AFPKOs).  The  estimation  systems  are  sophisticated  —  they 
include  programs  for  aggregating  cost  information,  determining  cost¬ 
estimating  relationships,  evaluating  learning  curves,  etc.  The  systems 
must  also  reflect  the  internal  accounting/estimation  system  of  the 
contractor  and  so  tend  to  be  very  diverse.  Air  Force  buyers  can  obtain 
extensive  data  on  a  contractor's  pricing  procedures  from  on-site  contract 
administration  offices.  Because  it  operates  in  a  complex,  data-rich 
environment  and  the  dollar  values  are  large,  systesui  command  procurement 
activities  have  developed  sophisticated  procedures  for  analysis. 
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2*4  Characterizing  Support  Requirements 

An  ideal  cost/price  analysis  system  would  have  the  following 
capabilities : 


(a)  Specify  and  support  specific  company  cost  models; 

(b)  Oser-friendly  interfaces  for  computer-based  systems; 

(c)  Standardization  within  companies  across  contracts  and  across 
companies  for  the  same  contract; 

(d)  Identification  of  cost-estimating  relationships  and  cataloging* 
and  the  ability  to  retrieve  forward  pricing  agreements; 

(e)  Access  to  field  data  available. 


Such  a  system  is  not  feasible  at  this  time  for  the  following  reasons: 


(a)  Historical  data  and  other  information  necessary  for  constructing 
such  models  is  not  available.  No  specific  models  exist  —  the 
general  models  that  do  exist  are  not  useful  for  pricing  specific 
items.  It  is  not  clear  that  current  data-gathering  procedures 
can  be  used  to  construct  such  models. 

(b)  Hone  of  the  computer  systems  that  we  have  evaluated  are  user- 
friendly.  The  design  history  of  many  of  these  systems  does  not 
facilitate  joint  use  and  makes  the  user  interface  very 
cumbersomQ.  The  current  design  of  many  of  these  systems  also 
makes  the  addition  of  an  user-friendly  interface  difficult. 

(c)  There  are  no  legal  requirements  for  standardization.  Cost 
Accounting  standards  do  not  provide  the  necessary  procedures  at 
an  appropriate  level  of  detail. 

(d)  Identifying  cost-estimating  relationships  or  other  relations 
between  an  item  and  parameters  of  the  manufacturing  company 
requires  centralized  access  to  standardized  production  data. 

Such  information  is  typically  not  available  for  small  purchases 
(and  occasionally  may  not  be  kept  by  the  company  either). 

(e)  Field  data  is  collected  in  many  instances,  but  not  available  to 
the  analyst.  To  make  it  uniformly  available  requires  a 
centralized  information  system.  Some  components  of  this  system 
are  already  in  place,  but  it  needs  to  be  extended  before  it  is  of 
significant  use. 

Our  recommendation  is  to  provide  subsystems  that  will  eventually  be  joined 
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to  provide  a  total  system.  Those  need  to  be  evaluated  at  the  different 
functional  levels  described  earlier  as  well. 

2.4.1  System  Alternatives 

Another  system  design  issue  has  to  do  with  the  level  and  sophistication 
of  the  "intelligence"  which  can  be  implemented  in  the  system.  We 
investigated  three  alternatives.  They  are: 

1.  Intelligent  Manual 

2.  Deductive  System 

3.  Data  rich  System 

These  are  elaborated  in  succeeding  sections. 

2.4.1 .1  Intelligent  manual 

An  intelligent  manual  is  an  interactive  expert  computer  system  that  does 
not  have  problem-solving  capabilities,  but  is  intended  to  guide  a  user  to 
performing  at  an  expert  level.  Such  a  system  can  be  constructed  at  several 
levels  of  complexity.  The  simplest  computer  manual  is  an  online  reference 
manual  that  would  point  the  user  to  information  that  might  be  needed.  The 
online  manual  itself  would  not  necessarily  contain  that  Information.  At 
the  next  level  of  complexity,  one  can  provide  a  spread  sheet  that  would 
help  aggregate  and  manipulate  data  as  well  as  offer  simulation 
capabilities.  This  is  similar  to  the  current  COFFER  IMPACT  system.  A 
system  that  provides  a  series  of  question-and-answer  procedures  to  aid  the 
user  in  using  stored  information  would  be  at  the  next  level  of  complexity. 
This  is,  in  essence,  an  elaborate  indexing  scheme  connected  with  the 
underlying  manual.  Next,  a  structured  trace  of  the  user  responses  to  the 
system's  questions  can  be  used  to  construct  a  descriptive  model  of  the 
contractor's  bid.  A  more  sophisticated  system  would  be  capable  of 
constructing  normative  models  of  the  contractor's  bid  based  on  the 
descriptive  models.  A  different,  but  not  unrelated,  objective  of  such  a 
system  would  be  to  provide  a  computer-aided  tutorial. 
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The  particular  characteristics  that  make  a  domain  appropriate  for  an 
intelligent  manual  are: 

-  Theoretical  knowledge  in  the  domain  does  not  necessarily  lead  to 
expertise  in  performing  the  tasks. 

-  There  is  considerable  knowledge  peculiar  to  specific  local 
situations. 

-  The  pure  problem-solving  aspects  of  the  task  are  overshadowed  by 
other  aspects  of  the  task,  ranging  from  mundane  information 
gathering  to  communication  with  other  humans . 

-  The  problest-solving  aspects  of  the  task  are  so  closely 
interleaved  with  other  task  components  that  a  system  oriented 
towards  problem-solving  support  would  not  be  appropriate. 

-  Any  computer-based  support,  whether  using  AI  technology  or  not, 
would  enhance  productivity  and  quality  of  the  overall  task 
performance.  Basically,  computer-support  for  the  non-problem 
solving  aspects  of  the  task  should  aid  rather  than  hinder  task 
performance . 

The  procurement  task  satisfies  these  constraints. 

2. 4.1 .2  Simple  Deductions 

A  system  capable  of  making  simple  deductions  on  its  own  requires  some 
reasoning  capabilities.  One  way  of  designing  such  a  system  is  to  construct 
a  subsystem  containing  a  control  structure,  one  having  a  capability  for 
making  historical  deductions  given  specified  relationships,  and  specialists 
that  can  be  called  when  specific  expertise  is  needed.  In  the  case  of  price 
analysis,  these  might  include  an  accounting  specialist,  management 
specialist,  auditing  specialist,  and  overhead  allocations  specialists.  The 
accounting  specialist  would  provide  information  mainly  concerned  with  cost 
accounting  standards,  financial  accounting  standards  and  interpretations, 
and  alternative  accounting  systems.  The  management  specialist  would 
provide  information  about  to  organisation  structure  and  management  strategy 
that  might  affect  to  contract  evaluation.  The  audit  specialist  would 
provide  information  obtained  by  on-site  personnel  (such  as  DCASPRs) 
including  company  pricing  policies,  consistency  of  application  of 
accounting  procedures,  prior  performance  history,  and  certification  of  cost 
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allocation  policies.  The  overhead  allocation  specialist  would  provide 
knowledge  related  to  allowable  cost  allocations,  procedures  for  allocations 
and  cost  pool  definitions. 

The  user  would  be  required  to  provide  the  systea  with  input  data  and 
also  respond  to  requirements  which  could  not  be  handled  by  the  system. 

These  circumstances  would  most  likely  be  encountered  where  the  price 
analyst  either  interfaces  with  other  specialists,  needs  information  not 
contained  in  the  system's  data  base,  or  where  very  sophisticated, 
unstructured  reasoning  is  required. 

2.4.1 .3  Data  Rich  Systems 

A  data  rich  system  would  be  the  ultimate  in  intelligent  systems  for 
contract  price  analysie.  It  would  have  the  capability  to  read  the 
contractor's  proposal  and  based  on  the  historical  and  analytic  data  in  the 
system,  analyse  the  contract  and  formulate  a  goverasent  position.  This 
requires  chat  the  syetem  have  access  to  the  technical  specifications  of  the 
buyer,  a  history  of  the  activity  in  purchasing  related  itsms,  a  history  of 
the  contractor's  performance  on  other  contracts,  a  history  of  similar 
contractors  and  similar  buys  as  well  as  the  logical  reasoning  capabilities 
required  to  analyse  the  the  current  contract  in  light  of  these 
considerations. 

A  data-rich  systea  is  appropriate  for  a  domain  in  which  most  of  the 
problem-solving  and  task  performance  can  be  put  online.  The  price  analysis 
task  (or  its  parent  procurement  task)  does  not  currently  meet  these 
conditions.  However,  one  may  aspect  these  conditions  to  hold  sometime  in 
the  future. 

2.5  Support  Alternatives 

We  consider  here  the  types  of  computer-based  assistance  feasible  for  the 
three  levels  of  price  analysis.  One  must  take  a  realistic  view  of  viable 
system  characteristics.  In  the  short  term,  an  intelligent  manual  is  a 
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realistic  alternative.  It  can  be  implemented  fairly  quickly,  will  not 
require  a  great  deal  of  personnel  retraining  to  implement,  and  does  not 
require  an  extensive  historical  data  base. 

The  types  of  assistance  that  could  be  provided  within  the  intelligent 
manual  alternative  at  the  the  base  level  are: 


1.  Provide  an  intelligent  manual  for  price  analysts  that  would 
guide  the  analysis  with  sequences  of  questions  and  by 
elaborating  and  explaining  issues  relating  to  these  questions. 

2.  Provide  general  indices  (e.g.,  Consumer  Price  Index,  Wholesale 
Price  Index)  and  specific  indices  (e.g.,  machine  tools  index) 
online. 

3.  Provide  data  bases  of  historical  contract  data  for  the  base,  the 
region,  and  the  Air  Force  as  a  whole. 

4 

4.  Provide  very  general  models  of  contractor  types. 

Potential  areas  of  assistance  at  the  AFLC  central  procurement  level  are: 

1.  Provide  general  and  specific  indices  online. 

2.  Make  available  data  bases  of  historical  contract  data. 

3.  Specify  general  parameters  for  analysis. 

4.  Provide  crude  cost  modeling  of  the  contractor's  estimation 

systems . 


Possible  assistance  at  the  Systems  Command  central  procurement  level 
inc lude : 


^These  models  are  functional  relationships  that  describe  cost  structures 
for  contractors  who  share  a  set  of  common  characteristics.  For  example, 
given  that  a  contractor  has  a  known  accounting  system  and  management 
strategy,  the  cost  estimation  system  could  be  expected  to  have  certain 
properties  in  common  with  other  contractors  using  the  same  accounting 
system  and  management  strategy. 
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1.  Provide  online  historical  data  bases. 

2.  Provide  guidance  in  establishing  parametric  and  predetexmined 

rates . 

3.  Provide  access  to  previously  established  parametric  and 
predetermined  rates. 

4.  Provide  contractor  specific  cost  models. 

An  intelligent  manual  will  be  of  the  most  benefit  at  the  base  level. 

Two  major  objectives  could  be  achieved.  First,  the  buyer  would  be  provided 
with  assistance  that  is  not  currently  available.  For  example,  the  user 
will  receive  informed  access  to  useful  tools  such  as  analytical  programs 
and  spread  sheets,  and  information  on  prior  buys,  catalog  listings  and 
pertinent  000  regulations.  The  intelligent  manual  will  also  provide 
guidance  and  structure  for  actually  carrying  out  the  evaluation  task.  This 
assistance  will  reduce  the  buyer's  dependence  on  a  price  analyst. 

Second,  contract  evaluation  can  be  expedited  by  increased  data 
availability  and  automated  document  preparation.  For  example,  the  Price 
Negotiation  Memorandum  (PNM)  could  be  automatically  generated  by  the  system 
from  the  buyer's  responses  to  the  system  during  evaluation.  A  trace  of  the 
buyer's  actions  while  analyzing  a  proposal  is  recorded  and  provides  an 
audit  trail  useful  for  evaluation  as  well  as  documentation.  The  uniform 
availability  of  the  intelligent  manual  would  facilitate  on-the-job 
training.  Buyers  could  increase  their  skill  level  without  expensive  formal 
training  programs.  Buyers  at  the  base  level  currently  do  not  have  access 
to  similar  capabilities  efficiently.  The  intelligent  manual  will  be 
applicable  to  all  procurement  actions  undertaken  at  the  base  level. 

An  intelligent  manual  will  not  be  as  advantageous  to  the  AFLC  central 
procurement  level  because  they  currently  have  access  to  some  computerized 
tools  for  analysis.  However,  central  procurement  would  be  improved  by 
access  to  on-line  data  access  as  well  as  access  to  spread  sheet 
capabilities  and  analytic  models.  Also,  an  intelligent  manual  would 
enhance  the  educational  capabilities  for  teaching  novice  buyers  more 
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sophisticated  price  analysis  procedures  and  requirements.  As  before,  an 
audit  trail  would  be  provided  along  with  assistance  in  completing  the  PNM. 

Pricing  functions  performed  at  the  Systems  Command  level  are  more 
complex  and  are  supported  by  more  sophisticated  tools.  The  initial 
prototype  system  developed  here  (or  even  the  first  full-scale  expert  system 
for  contract  pricing)  would  not  necessarily  be  an  improvement.  These 
preliminary  systems  implemented  for  base  and  central  procurement  can  grow 
into  the  kinds  of  systems  that  would  be  useful  at  the  systems  level.  This 
growth  will  depend  on  the  acceptance  of  the  system  and  participation  in  its 
development  by  the  AF  pricing  community. 

The  current  level  of  computer  support  available  at  the  systems  level  is 
desirable  at  the  base  and  central  levels.  The  proposed  system  can 
facilitate  the  transfer  of  this  support.  For  example,  parametric 
estimators  and  coet  estimation  ratios  would  be  useful  at  all  levels, 
especially  at  the  base-level  where  little  pricing  assistance  exists 
currently.  Implementation  of  the  intelligent  manual  system  would  allow 
data  to  be  gathered  and  technology  to  be  disseminated  that  could  be  used  to 
construct  such  a  system  in  the  future.  The  relationships  established  from 
evaluating  the  first  system  will  be  the  basis  for  constructing  a  simple 
deductive  system.  This,  in  turn,  will  be  the  basis  for  constructing  a  data 
rich  system  for  price  analysis.  Each  level  is  the  building  block  for  the 
next,  improved,  expert  computer  system. 
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3.  AHALYSIS  OF  THE  COHTSACT  PRICE  TASK 

3.1  Introduction 

The  following  analysis  is  based  heavily  on  the  Armed  Services 
Procurement  Regulation  Manual  (ASPM-1)  on  Contract  Pricing.  ASPM-1  is  a 
well-organized  description  of  the  Cash  of  price  and  cost  analysis,  though 
it  is  apparently  more  praised  than  used  in  practice.  ASPM-1  makes  clear 
the  organization  of  Che  cost/price  analysis  task  and  the  relation  between 
the  internalized  knowledge  of  the  price  analyst  and  the  task.  This 
analysis  is  a  necessary  prelude  to  the  design  and  organization  of  the 
intelligent  manual  for  cost/price  analysis. 


3*2  A  multi-level  model  of  cost  analysis 

Cost  analysis  is  performed  at  four  distinct  functional  levels.  These 
are:  the  Contract  Negotiation  Level,  the  Contract  Accounting  Level,  the 
Work  Breakdown  Structure  Level,  and  the  Line-Item  Level.  The  relation 
between  these  levels  is  approximately  top-down  —  the  Contract  Negotiation 
(or  the  Negotiation  Level)  is  the  highest,  while  the  Line- Item  Level  is  the 
lowest;  the  Contract  Accounting  Level  (or  the  Accounting  Level)  and  the 
Contract  Work  Level  (or  the  Work  Level)  are  at  roughly  the  same 
intermediate  level. 

The  general  features  of  the  model  are: 

1.  A  set  of  levels  corresponding  to  a  breakdown  of  the  contract 
into  sub-entities, 

2.  A  set  of  questions  peculiar  to  each  level  that  the  analyst  must 
ask  and  answer, 

3.  Operations  peculiar  to  each  level  (primarily  aggregation  and 
quantity  determination),  and, 

4.  Information  bearing  entities  whose  structure  is  unique  to  the 
level. 
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We  define  the  levels  of  our  cost  analysis  model  and  discuss  each  in 
detail  in  the  following  paragraphs. 

3.2.1  Contract  Negotiation  Level 

This  highest  level  views  the  task  in  terms  of  the  contract  as  a  whole. 
Certain  global  variables  and  parameters  of  the  contract  have  to  be 
determined.  These  include,  among  others: 

1.  The  contract  amount  (and  its  range), 

2.  The  contract  structure, 

3.  The  contract  type, 

4.  Data  availability,  and, 

5.  The  Statement  of  Work,  or  the  Work  Breakdown  Structure  (WBS). 

Also,  at  this  level,  certain  global  decisions  have  to  be  made  —  for 
example,  is  the  situation  competitive,  or  should  each  offer  be  evaluated 
with  respect  to  independent  standards,  or  should  the  offers  be  analyzed  in 
greater  detail. 

3.2.2  Contract  Accounting  Level 

This  level  consists  of  the  accounting  categories  into  which  an  offer  can 
be  partitioned.  In  operational  terms,  this  level  consists  of  aggregation 
nodes  organized  as  a  hierarchy.  A  cost  estimate  at  each  node  is  the 
weighted  sum  of  the  cost  estimates  of  lover  nodes  in  the  hierarchy.  The 
Accounting  level  identifies  elements  of  the  contractor's  cost  accounting 
system  with  items  in  the  statement  of  work.  It  may  also  connect  the  WBS 
with  cost-specifiable  items  in  the  contract.  Most  contracts  display  two 
primary  Accounting  level  nodes:  Direct  costs  and  Indirect  costs.  Within 
Direct  costs,  there  are  Materials,  Factory  Labor,  Engineering  Labor, 

Tooling  costs,  and  any  other  Direct  costs.  Within  Indirect  Costs  there  are 
a  number  of  categories  (see  page  5A-44  of  ASPM-1).  Each  node  suggests  a 
set  of  questions  to  the  price  analyst  —  these  questions  constitute  the 
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expert  knowledge  associated  with  that  node  and  can  be  obtained  from  the 
technical  literature  (for  example,  ASPM-1  page  4-B-27  provides  a  list  of 
summary  questions  about  direct  factory  labor  costs). 

3.2.3  Contract  Vork  Level 

This  level,  like  the  Accounting  Level,  is  also  an  aggregation  level. 
However,  unlike  the  Accounting  level,  this  level  identifies  items  peculiar 
to  the  particular  contract  or  statement  of  work.  The  structure  of  the  Work 
level  is  often  obtainable  from  the  Statement  of  Work  specified  in  the 
solicitation  (or  in  a  related  WBS).  The  Work  level  is  orthogonal  to  the 
Accounting  Level  in  that  the  same  (or  similar)  cost  items  may  be 
distributed  differently  over  different  entities  in  the  two  levels.  Usually 
there  is  a  simple  relationship.  For  example,  an  Accounting  level  entity 
such  as  Factory  Labor  can  be  broken  down  at  the  Work  level  into  particular 
items  by  task,  say.  Factory  Labor  for  each  of  ten  different  widgets.  The 
Labor  amount  for  each  widget  will  be  classified  into  different  kinds  of 
labor  at  different  rates.  At  this  level,  the  analyst  decides  if  some 
component  or  entity  is  necessary  for  the  contract,  whether  the  composition 
of  a  charged  item  is  correct,  and  whether  the  calculation  proposed  is  being 
done  correctly  (for  example,  is  a  cost  pool  defined  correctly  to  include 
only  relevant  work).  This  level  also  identifies  the  questions  raised  about 
specific  items.  The  general  form  of  these  questions  is  established  by  the 
Accounting  level  node  that  includes  the  item,  but  the  analyst  must  modify 
the  question  to  apply  it  to  the  specific  item  (e.g.,  the  summary  questions 
mentioned  above  from  ASFM-1,  page  4B-27,  for  Direct  factory  Labor  costs 
must  be  converted  to  questions  about  a  particular  item  and  answered  with 
reference  to  that  item) . 

3.2.4  Line-item  Level 

At  this  level  an  estimate  is  directly  generated  for  an  item.  For 
example,  the  contractor  may  estimate  2  hours  of  assembly  labor  for  widget 
#5  at  $7.93  per  hour.  This  estimate  may  correspond  to  some  specific  line 
item  in  the  contract  (but  need  not).  At  this  level,  the  analyst  is 
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required  to  decide  whether  the  rate  $7. 95/hour  is  correct,  and  the  changes 
that  may  be  necessary. 

3.2.5  Characteristics  of  the  levels 

The  Accounting  Level  and  the  Work  level  are  not  strictly  subordinate  to 
each  other.  There  is  some  evidence  (both  from  the  nature  of  the  task  and 
from  the  organization  of  COPPER  IMPACT  programs)  that  they  should  be 
considered  "equal"  or  coordinate  levels. 

Every  level  is  almost  independent  of  other  levels,  except  for 
connections  made  via  common  global  state-variables  defined  for  the 
Negotiation  level.  The  Contract  Accounting,  the  Contract  Work,  and  the 
Line-item  levels  are  frame-based  levels  —  the  structure  of  the  entities  at 
these  levels  can  be  described  a  priori  with  frame-like  structures.  As 
indicated  above,  price  analysis  may  occur  at  the  Line-item  level;  this 
analysis  determines  if  a  particular  price  on  a  particular  contract  is 
appropriate . 

The  Negotiation  level  is  not  a  frame-based  level  —  it  depends  on  the 
results  returned  from  the  lower  levels  to  make  decisions  about  the  contract 
as  a  whole.  Decisions  at  the  Negotiation  Level  may  result  in  re-evaluation 
at  all  other  levels.  The  rest  of  this  chapter  describes  these  levels  in 
further  detail. 

3.3  The  Contract  Negotiation  Level 

The  contract  negotiation  level  reflects  the  economic  and  political 
environment  faced  by  the  contracting  parties  and  determines  the  global 
parameters  within  which  the  negotiations  must  take  place.  At  this  level, 
the  analyst  considers  the  following  issues: 

1.  Contract  situation:  The  context  of  the  proposal  is  important 
—  competitive  situations  are  preferred  as  they  are  believed  to 
lead  to  a  fair  market  price  for  the  product.  However,  the 
analyst  must  determine  that  a  competitive  situation  exists.  If 
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competition  is  absent,  some  other  basis  for  determining  a  fair 
price  must  be  found.  The  situation  determines  the  procedures  and 
regulations  that  govern  the  analyst's  approach  to  the  price 
analysis  problem. 

2.  Contract  contingencies:  Offers  usually  have  contingencies  and  the 
analyst  must  allow  for  these.  These  include:  labor  or  material 
price  escalation;  changes  in  manufacturing  process;  changes  in 
tax  rates,  and  so  on.  These  contingencies  affect  the  offerer's 
ability  to  perform  the  contract.  Recognizing  them  is  central  to 
negotiating  a  fair  agreement. 

3.  Cost  proposals  and  contract  components:  (specified  in  DD  633 
forms)  The  offerer  may  be  required  to  submit  a  proposal 
specifying  the  cost  and  its  breakdown  into  more  specific 
components.  Under  certain  circumstances,  the  offerer  may  be 
required  to  submit  different  kinds  of  DD-633  forms  that  break  the 
proposed  cost  down  in  other  ways.  The  proposal  and  the  DD-633 
forms  constitute  the  offerer's  justification  for  the  offered 
price.  The  analyst  must  determine  if  proposed  costs  are  to  be 
allowed  or  not;  if  special  circumstances  claimed  by  the  offerer 
apply  or  not,  and  so  on. 

4.  Contract  pricing  arrangements:  Different  pricing  arrangements  are 
a  response  to  the  differential  distribution  of  risk  or 
obligations  between  the  contractor  and  the  government.  All 
contract  situations  involve  uncertainty  — •  this  includes 
uncertainty  in  performance  (especially  for  R&D  contracts), 
uncertainty  in  the  price  of  primary  factors,  and  uncertainty  in 
the  quality  of  product.  The  basic  distinction  is  between  fixed- 
price  contracts  (in  which  the  risk  is  largely  borne  by  the 
contractor)  and  cost-plus  contracts  (in  which  the  risk  is  largely 
borne  by  the  government);  however  modifications  to  these  basic 
forms  can  result  in  a  wide  variety  of  pricing  arrangements. 

5.  Cost  accounting  systems  and  principles:  The  government  has  rules 
that  specify  how  and  why  specific  kinds  of  costs  are  allowed  (or 
disallowed).  The  cost  accounting  system  of  che  contractor  is 
crucial  to  the  identification  of  such  costs.  There  are  a  variety 
of  cost  accounting  systems  in  use.  Such  systems  usually  develop 
in  response  to  the  contractor's  need  for  information  on  its  own 
operations,  and  so  there  can  be  considerable  variation  in  the 
accounting  systems  used  by  different  contractors. 


^Though  getting  a  low  price  is  an  objective  for  the  price  analyst,  it  is 
not  the  primary  objective  —  the  price  analyst  must  determine  a  "fair  and 
reasonable  price",  not  a  price  that  would  ruin  a  contractor,  nor  should  he 
arbitrarily  reduce  the  contractor's  profit  margin.  » 
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Cost  estimating  systems:  Most  contractors  use  cost  estimating 
methods  and  procedures  in  determining  their  offers.  The  function 
of  such  estimation  systems  is  to  help  company  management,  and 
under  certain  circumstances,  this  information  is  available  to 
government  analysts.  Estimation  methods  are  tied  to  cost 
accounting  methods  --  like  accounting  methods,  they  also  vary 
videly  from  company  to  company  and  often  between  divisions  of  the 
same  company. 


In  Chapter  4,  ve  present  an  intelligent  manual  that  helps  the  buyer 
determine  the  actions  to  take.  For  example,  whether  price  analysis  or  cost 
analysis  is  undertaken  depends  to  a  large  extent  on  the  availability  of  the 
necessary  information.  This  decision  is  made  at  the  contract  negotiation 
level.  The  procedures  to  be  followed  at  later  stages  are  dictated  by  this 
decision. 


In  particular,  at  the  negotiation  level,  the  analyst  decides  whether  to 
evaluate  information  at  the  accounting  or  work  levels.  One  consequence  of 
deciding  to  perform  price  analysis  (as  opposed  to  cost  analysis)  is  that 
the  analyst  decides  not  to  use  accounting  or  work  level  information  or 
procedures.  The  analyst  may  still  use  line-item  level  methodology  for 
price  analysis  (this  is  the  degenerate  case  of  a  single  item).  Decisions 
at  the  negotiation  level  also  determine  the  forms  and  regulations  that  the 
analyst  vill  attempt  Co  apply  to  a  proposal.  For  example,  the  analyst 
decides  whether  to  use  the  "weighted  profits  guideline"  form  for  assessing 
a  reasonable  profit  in  a  particular  case  at  the  negotiation  level. 


3.4  The  Contract  Accounting  Level 

As  mentioned  earlier,  this  level  is  an  aggregation  level.  There  are 
three  major  categories  into  which  cost  items  can  be  aggregated: 

1 .  Direct  Costs 

2.  Indirect  Costs 


3.  Profit 
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Direct  Costs 

Materials 
Factory  Labor 
Engineering  Labor 
Tooling 
Other 

Indirect  Costs 

Material  overhead 

Engineering  overhead 

Manufacturing  overhead 

General  and  Administrative  Expenses 

Figure  1:  Accounting  Level:  Direct  and  Indirect  Costs  breakdown 

Each  of  these  categories  are  broken  down  further  —  Figure  1  shows  the 
first-** level  of  such  a  breakdown  for  Direct  and  Indirect  Costs.  Associated 
with  each  category  there  are  a  "typical"  set  of  questions  to  be  asked  or 
problems  to  be  solved. 

Since  the  accounting  level  is  an  aggregation  level,  many  of  the 
operations  performed  by  the  analyst  appear  routine  and  mechanical.  This 
has  resulted  in  attempts  to  automate  this  level.  For  example,  the  PPS 
program  (for  Proposal  pricing  System)  in  the  COPPER  IMPACT  system  provides 
support  in  laying  out  the  structure  of  a  contract  in  accounting  level  terms 
and  for  performing  simple  calculations  on  this  structure.  However,  there 
is  more  to  the  accounting  level  than  addition  —  certain  deep  questions 
about  the  offer  are  raised  and  answered  st  this  level.  These  deep 
questions  are  less  easily  mechanised  and  will  cause  difficulties  in  regular 
use  of  any  PPS-Like  system.  For  example,  the  analyst  must  ask  the 
following  questions  of  every  Direct  Cost  item: 

1.  What  is  it? 

2.  Where  is  it? 

3.  What  does  it  represent? 

4.  How  was  it  used? 
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A  PPS-like  system  cannot  answer  these  questions.  These  questions  must  be 
answered  at  this  level  in  the  appropriate  way.  Similar  and  more  detailed 
questions  can  be  raised  at  every  node  of  the  accounting  level  hierarchy. 

3.5  The  Contract  (fork  Level 

The  contract  work  level  corresponds  roughly  to  the  WBS  of  the  task 
(specified  by  the  Statement  of  Work  (SOW)  specified  in  the  RFP  or  other 
solicitation).  The  entities  at  this  level  are  specified  by  the  domain  of 
the  contract.  For  example,  the  task  of  constructing  a  power-plant  consists 
of  two  subtasks:  (1)  constructing  the  turbine,  and,  (2)  constructing  the 
housing  facility.  The  turbine  task,  in  turn,  consists  of  (1)  the 
electrical  system,  and,  (2)  the  mechanical  system. ^  This  hierarchy  is 
additive  —  i.e.  the  coat  for  the  power-plant  is  the  sum  of  the  costs  for 
the  turbine  and  the  housing  facility  sub-tasks. 

The  work  level  is  an  aggregational  level  (like  the  accounting  level). 
However,  there  is  more  to  it  than  addition.  The  work  level  provides  the 
justification  for  the  particular  design  decisions  and  cost  choices  made  by 
the  contractor  —  e.g.,  if  the  contractor  specifies  (at  a  lower  level)  that 
ten  transistors  are  needed  for  the  electrical  system  of  the  turbine,  he 
must  explain  why  (or  the  analyst  must  ask  why)  ten  transistors  are  needed. 
Again,  if  the  contractor  proposes  twenty  hours  of  skilled  labor,  the 
analyst  must  determine  if  this  is  an  appropriate  amount  of  time  for  the 
task.  Such  decisions  are  made  at  the  work  level. 

It  should  be  noted  that  there  are  commonalities  between  questions  raised 
at  the  work  level  and  at  the  accounting  level.  The  answers,  however,  are 
phrased  differently.  For  example,  the  work  level  answer  is  in  response  to 
the  question  "Why  is  this  needed"?  At  the  accounting  level,  the  answer  is 
to  determine  "Why  in  this  category"?  The  same  low-level  entity  may  be 


^This  example  is  taken  from  the  PPS  manual  of  COPPER  IMPACT. 
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queried  ia  both  esses.  There  ere  clearly  close  links  between  the 
accounting  and  work  levels  in  practice. 

3.6  The  Line- Itea  Level 

a 

The  line-itea  level  is  the  one  at  which  price  analysis  properly  occurs. 
For  every  line-itea,  the  analyst  must  ask:  "Is  the  price  specified  for  this 
item  correct"?  The  necessity  for  the  itea  has  already  been  established  at 
the  work  level;  the  accounting  category  (or  categories)  in  which  the  itea 
is  to  be  included  has  been  deterained  at  the  accounting  level;  the  only 
thing  left  to  deteraine  is  the  fairness  of  the  unit  price. 

At  this  level,  items  look  like  frames^  with  at  least  one  unfilled  slot 
(the  slot).  Depending  on  the  techniques  to  be  used,  there  nay  be 

other  slots  that  must  be  filled  also  (such  as,  the  iustif ication  for  a 
selected  price,  or  the  Source  of  an  estinate,  etc.).  That  is  to  say,  the 
line-itea  level  is  a  frame  level  —  all  entities  at  this  level  are  frsaes 
with  associated  procedures  and  aodels  for  providing  values  for  slots. 

Slots  in  a  frane  can  also  provide  aechanisas  for  determining  the  value  of 
other  slots  in  the  sane  franc  (or  in  related  fraaes).  For  example,  the 
techniques  to  be  used  for  establishing  an  itea's  fair  price  depend  on  a 
number  of  factors,  such  as:  a  market  price  if  any,  the  production  cost  plus 
profits,  a  competitive  price,  inflation  rates  since  the  last  purchase  (at  a 
fair  price),  technology-dependent  factors,  learning  curves  based  on 
production  experience,  etc..  These  techniques  constitute  the  options  in  a 
Price-gstablishaaot-techniaue  slot  in  a  line-itea.  Some  of  these 
techniques  apply  to  certain  kinds  of  line-items  sad  not  others. 

Being  a  fraae  level,  a  number  of  intelligent  data-base  operations  can  be 
performed  on  line-items.  For  exaaple,  line-iteas  aay  be  related  in  a  type 


^Frames  and  slots  are  technical  tens  in  the  expert  systea  area.  Bough ly 
speaking,  a  fraae  is  analogous  to  a  fon  and  a  slot  in  a  fraae  is  analogous 
to  an  entry  on  a  fon 
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hierarchy  (a  "jeweled  bearing"  is  a  type  of  "bearing",  and  so  is  a  "metal 
bearing").  Items  of  related  type  may  have  common  slots,  common  procedures 
for  filling  slots,  or  other  commonalities  that  may  be  relevant  for  pricing 
the  item  (or  performing  other  functions  on  them). 

3.7  Validating  the  theory 

The  above  task  analysis  is  based  on  the  description  of  the  task  in 
textbooks  and  manuals.  It  needs  to  be  validated  by  studies  of  cost  and 
price  analysis  as  performed  in  practice.  We  propose  to  design  cases  in 
price  and  cost  analysis  to  perform  these  studies. 

We  will  evaluate  these  studies  by  "protocol  analysis".  Protocol 
analysis  has  been  widely  discussed  in  the  cognitive  psychological 
literature  [4].  The  procedure  consists  of  analyzing  an  intensive  verbal 
record  of  a  problem-solver  (in  this  case,  a  buyer  or  a  price  analyst) 
solving  a  problem  (in  this  case,  analyzing  a  price  proposal). 

Protocol  analysis  is  necessary  partly  because  the  usual  record  of  a 
finished  negotiation  (the  Price  Negotiation  Memorandum,  or  the  PHM)  is 
virtually  useless  from  an  analytic  viewpoint.  The  PNM  is  a  post-decision 
record  of  the  results  and  gives  very  little  information  on  the  processes 
used  by  the  price  analyst  in  coming  to  her  conclusion. 

The  PHMs  of  about  30  different  cases  provided  by  the  Air  Force  have  been 
examined.  These  PHMs  were  accompanied  by  varying  amounts  of  documentation 
on  the  cases.  Unfortunately,  there  appeared  to  be  little  consistency  from 
document  to  document.  From  this  basic  set,  the  research  group  has  begun 
constructing  realistic  case  studies  that  consist  of: 

1.  The  solicitation  and  amendments. 

2.  The  statement  of  work  and  amendments. 

3.  The  price  proposal  of  the  contractor^ )  (this  is  often  simply  a 
filled-in  version  of  the  solicitation  and  the  SOW). 
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4.  DO-633  forms  (if  submitted  by  the  contractor^ )) . 

5.  Other  documentation  submitted  by  the  contractor^  )  (such  as,  a 
cover  letter,  supporting  evidence  for  claimed  prices,  etc.). 

6.  The  Audit  report  and  other  associated  technical  reports  (if 
these  have  been  requested). 

7.  The  transmittal  letter  from  the  buyer  to  the  price  analyst  (if 
the  analysis  is  to  be  performed  by  a  price  analyst  and  not  the 
buyer ) . 

8.  The  PHM  (this  is  not  shown  to  the  price  analyst  studying  the 

case). 

Protocol  analysis  will  enable  us  to  validate  our  model  of  the  task  as 
described  in  this  chapter  and  to  estimate  how  significant  different  parts 
of  it  are  in  actual  practice.  It  will  also  enable  us  to  identify  any 
additional  heuristic  rules  and  schemas  used  by  buyers  (or  price  analysts) 
in  making  their  decision. 


1  Base  Buyer 

i 

Base  P.A. 

Central  P.A.  I 

Competitive  1  3 

i 

3 

1  ! 

Catalog  I  3 

-----  .  |  _  --  , 

3 

1  1 

Market  i  3 

-  -  ,  •  .  -  - 

3 

i  i 

Prior  Quote  1  3 

3 

i  l 

A  1 

Table  2:  Cases  being  developed  for  protocol  analysis 


Table  2  shows  the  number  of  cases  in  each  of  four  price  analysis 
categories  and  two  procurement  levels  that  are  being  developed.  At  least 
one  case  from  each  of  the  following  areas  of  procurement  has  been  included 

1.  Construction 


2.  Supplies 

3 .  Services 
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4.  Spere  parts 

He  will  concentrate  on  base- level  procurement  and  price  analysis,  but 
will  pay  some  attention  to  central  procurement,  this  basic  decision  was 
explained  in  the  preceding  chapter  and  accounts  for  the  larger  number  of 
base- level  cases  in  the  above  set.  Also,  our  cases  should  be  designed  so 
that  a  price  analyst  or  buyer  will  be  able  to  solve  a  case  in  less  than  2 
hours.  In  particular,  it  is  expected  that  a  typical  base-level  case  should 
only  take  about  20  minutes  and  the  longest  base- level  case  should  take  less 
than  an  hour. 
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4.  A  STSTZM  FOR  PRICE  ANALYSIS 

Price  analysis  is  performed  almost  entirely  at  the  contract  negotiation 
level  with  occasional  Forays  into  the  line-item  level.  A  model  for  this 
task  is  presented  in  the  following  section  (4.1).  Based  on  this  analysis, 
an  intelligent  manuel  is  implemented  in  a  locally  available  information 

Q 

system  called  XINFO.  This  system  is  described  in  section  4.2.  In  the 
coarse  of  implementation  in  XINFO,  of  using  the  system,  and  of  displaying 
the  system  to  price  analysts,  problems  with  the  analysis  were  identified. 
Also,  other  limitations  of  the  XINFO  system  made  the  design  less  than 
ideal.  Work  has  begun  on  a  different  analysis  (presented  in  section  4.3), 

q 

that  will  be  implemented  on  a  different  system,  called  ZOG.  The  new 
implerantation  is  described  in  section  4.4.  Both  XINFO  and  ZOG  are  also 
described  in  a  little  greater  detail  in  Appendices  II  and  III. 

4.1  A  Model  for  Price  Analysis 

Price  analysis  the  task  of  determining  which  comparison  technique  is 
appropriate  for  a  given  contract,  performing  the  selected  technique,  and 
making  the  award  as  a  result  of  this  comparison.  There  are  four  comparison 
techniques  as  shown  in  Figure  2,  eech  differing  from  the  rest  in  the 
complexity  of  the  comparison.  The  first  comparison  technique  is 
Competitive.  In  this  technique,  the  price  analyst  (or  PA)  compares  the 
contract  to  other  current  offers  submitted  in  the  spirit  of  competition. 

If  competition  is  not  possible,  the  PA  uses  the  second  technique 
—  comparing  the  contract  to  published  prices.  If  that  is  not  appropriate, 
the  PA  uses  the  third  technique  of  Secondary  Comparisons,  i.e.,  comparing 
the  proposal  to  a  price  determined  by  some  other  means,  such  as  old 


®XINFO  is  a  version  of  INFO,  a  system  designed  at  MIT. 

^ZOG  is  a  system  designed  at  Carnegie-Mellon  University.  Dr.  Kamesh 
Ramakrishna,  one  of  the  principal  investigators  on  this  project,  was  one  of 
the  designers  of  ZOG. 
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contracts,  cost  estimation  models,  and  other  government  estimates. 

Finally,  when  all  else  fails,  the  PA  is  forced  to  look  at  the  purchased 
item  and  make  an  "educated  guess"  as  to  what  price  is  fair  and  reasonable. 
Ve  call  such  methods  Delphic  methods. 


Price 

Analysis 


! 


! 

I 


| - 1  | - 1  | - 1 

I  Competitive  I  I  Published  I  I  Secondary  I 

I  I  I  Price  I  1  Comparisons  I 


-  specifications  -  regulated 

-  independence  -  catalog  or 

-  exceptions  market? 

-  more  than  one? 


I  Delphi  I 
1  Methods  I 


- 1 

Prior  Quotes  I 

ICost  Estimating! 

I  Government  1 

i - 

!  Value 

1 

1 

1  Relationships  I 
!  —  -  —  1 

I  Estimates  1 

I  Analysis 

Figure  2:  Model  of  the  Price  Analysis  Task 


4.1.1  Competitive:  Comparison  to  Current  Offers 

Competitive  pricing  is  applicable  when  competition  exists.  If  it  does, 
the  process  is  relatively  simple.  Determining  whether  or  not  a  competitive 
situation  exists  is  also  simple  (most  of  the  time).  Guidelines  exist  for 
determining  if  competition  exists.  A  short  sequence  of  simple  (YES/NO) 
decisions  suffices.  If  competition  exists,  the  PA  selects  the  low  bidder, 
unless  the  situation  is  exceptional  for  some  reason.  This  can  be 
determined  with  a  sequence  of  simple  yes/no  questions  too.  In  the  case  of 
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an  exception,  competitive  comparison  cannot  be  applied.  However,  this  does 
not  mean  that  the  low  contract  is  unacceptable,  merely  that  another 
comparison  technique  must  be  used  to  justify  the  price  of  the  low  contract. 

There  are  four  criteria  for  competitive  pricing  (as  specified  by  DAR 
3-807 .7): 

1.  Each  offer  must  meet  the  technical  specifications  of  the 
contract, 

2.  Each  offer  must  meet  the  pricing  specifications  of  the  contract, 
and 

3.  Each  offer  must  have  been  submitted  independently, 

4.  There  must  be  at  least  two  offers. 

After  taking  the  appropriate  action,*®  the  PA  determines  if  an  exception 
exists  by  checking  the  following  three  criteria  (DAS.  3-807.7): 

1.  The  solicitation's  requirements  must  not  be  such  so  as  to 
eliminate  some  potential  offerers  from  competing, 

2.  The  lowest  bidder  must  no.t  have  a  "lock-on"  the  competition 
(i.e.,  some  advantage  that  allows  this  contractor  to  be  lower 
than  the  other  contractors  such  as  no  need  for  start-up  costs), 
and, 

3 .  The  lowest  bidder  must  not  be  too  high  (based  on  the  government 
estimate  supplied  by  the  user  or  determined  by  the  funds 
allocated  for  the  procurement  by  the  funding  agency). 

4.1.2  Comparison  to  Published  Price 

Comparison  to  published  prices  is  the  primary  method  for  dealing  with 
"sole-source"  contracts.  In  addition,  the  method  is  applicable  if  the 
price  for  the  item  is  regulated  by  the  government  or  there  exists  a  catalog 


*^The  "appropriate  action"  can  either  be  the  removal  of  unqualified 
offers  from  consideration  or  a  request  for  re-submission  of  such  an  offer. 
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or  market  price  for  the  item.  Given  this,  the  following  three  criteria 
must  be  confirmed  (DAR  3-807.7  (b)): 

1.  The  item  must  be  a  commercial  item, 

2.  The  item  must  be  one  that  is  sold  in  substantial  quantities, 
and, 

3.  The  item  must  be  sold  to  the  general  public. 

If  these  criteria  are  confirmed  the  PA  determines  whether  or  not  the  price 
is  fair  and  reasonable  by  comparing  the  price  for  the  item  on  the  contract 
to  Che  published  price. 

4.1.3  Secondary  Comparisons 

Secondary  comparisons  requires  that  the  PA  independently  develop  a 
price.  This  may  require  some  significantly  more  complex  decisions  be  made. 
A  number  of  different  methods  for  developing  a  price  exist.  They  include, 
comparison  to  prior  contracts  or  quotes,  use  of  cost  estimating 
relationships,  comparisons  to  government  estimates,  and  value  analysis. 
Comparing  to  prior  quotes  requires  knowledge  of  past  contracts  and  the 
ability  to  quickly  recognize  those  past  contracts  that  are  the  same  as  or 
similar  to  the  current  one.  It  also  requires  the  ability  to  determine  the 
differences  —  in  technologies,  environmental  factors  (different  tax  laws, 
etc.),  specifications  (differences  in  the  technical  aspects  of  the  product) 
and  historical  differences  (effects  of  inflation,  etc.)  —  in  the  two 
contracts.  Finally,  the  PA  must  be  able  to  use  this  information  to 
determine  if  the  present  contract  is  indeed  fair  and  reasonable.  This 
structure  of  the  method  is  shown  in  Figure  3.  Similar  structures  can  be 
constructed  for  the  other  methods . 

Figure  3  is  a  modular  decomposition  of  the  prior  quote  comparison 
method.  The  basic  components  are: 

1.  The  Contract  Record  (CR)  Module  gives  the  Prior  Quotes  (PQ) 

Expert  a  number  of  prior  contracts  which  are  similar  to  the 
present  one. 
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2.  PQ  gives  the  Technology  Difference  (TD)  Module  these  similar 
contracts  and  TD  returns  to  PQ  only  those  contracts  that  do  not 
have  significant  differences  in  technologies. 

3.  PQ  gives  the  Environmental  Difference  (ED)  Module  these 
contracts  and  ED  returns  to  PQ  only  those  contracts  that  do  not 
have  significant  differences  in  accounting  standards. 

4.  PQ  gives  to  the  Specification/Historical  (S/B)  Module  the 
contracts  that  have  passed  both  the  above  criteria  and  S/H 
identifies  the  differences  in  technical  specifications  and 
historical  differences  between  the  proposal  and  the  contracts. 

5.  PQ  uses  these  comparative  lists  to  determine  a  fair  and 
reasonable  price  for  the  contract. 
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Figure  3:  Prior  Quotes  Expert 
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4.1.4  Delphi  Methods 

As  a  last  recort,  the  FA  must  determine  reasonableness  based  on  very 
little  information.  Visual  Analysis  is  an  example  of  a  Delphic  method 
—  it  is  based  on  a  visual  inspection  of  an  item,  or  the  drawing  of  an 
item,  or  sometimes,  any  other  description,  in  order  to  come  up  with  an 
approximate  estimate  of  the  probable  value.  Such  a  process  requires  the 
most  complex  form  of  comparison;  thus  specifying  adequate  guidelines  is 
very  difficult.  Because  of  its  lack  of  objectivity,  this  technique  is  used 
as  a  last  resort. 

4.2  The  Price  Analysis  Tutorial  and  Intelligent  Manual 

We  used  the  above  structure  for  price  analysis  to  design  and  implement  a 
tutorial-cum-intelligent  manual  for  price  analysis.  This  was  implemented 
in  an  information  system  called  XINFO  (see  Appendix  II  for  further 
information  on  XINFO).  The  initial  implementation  was  restricted  to 
Competitive  and  Catalog  pricing  situations.  The  tutorial  assumes  that  a 
base-level  buyer  is  analyzing  offers  made  by  one  or  more  contractors.  The 
system  then  guides  the  buyer  through  the  decisions  to  be  made,  provides 
explanation  on  actions  to  be  taken,  and  gives  the  buyer  access  to 
definitions  and  examples  of  these.  The  structure  of  this  system  is 
described  below.  Appendix  II  contains  an  example  of  a  buyer  making  a 
decision  in  a  competitive  situation. 

XINFO  is  a  computer  information  system  that  organizes  information  as  a 
set  of  nodes  arranged  in  a  tree- like  network  called  an  INFO-net.  This 
INFO-net  contains  any  number  of  subnets.  The  Price  Analysis  Tutorial 
requires  two  subnets:  a  Problem  Solving  net  and  a  Learning  net.  The  user 
of  this  tutorial  is  guided  through  the  Problem  Solving  net  via  a  series  of 
nodes  where  the  user  is  given  the  opportunity  to  take  actions  and  make 
decisions  or  learn  more  about  the  contract  pricing  domain. 
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4.2.1  Problem  Solving  end  Learning  Hats 

There  are  two  separate  nets  -  the  Problem  Solving  net  (PS-net)  and  the 
Learning  net  (L-net).  The  PS-net  contains  DECISION /ACTION  nodes  (see 
Figure  4)  that  direct  the  price  analyst  in  analyzing  a  contract.  The  L- 
net ,  on  the  other  hand,  gives  general  knowledge  about  a  given  subject.  For 
example,  for  Competitive  pricing,  the  PS-net  would  identify  the  decisions 
necessary  for  determining  that  a  situation  is  competitive,  whereas  the  L- 
net  would  explain  (in  economical  terms)  the  meaning  of  and  degrees  of 
competition.  In  the  PS-net,  the  user  (price  analyst)  is  guided  through  the 
net  via  DECISION /ACTION  nodes.  Each  major  decision  may  be  answered  subject 
to  review  or  may  be  elaborated  into  a  number  of  smaller  decisions.  Figure 
4  shows  the  conventions  that  have  been  followed  in  the  XINFO 
implementation. 

4.2.2  DECISION/ACTION  nodes 

Decisions  must  be  made  and  actions  must  be  taken  during  price  analysis. 
The  XINFO  net  contains  three  different  types  of  nodes.  DECISION  nodes  aid 
the  price  analyst  in  making  important  decisions.  The  decision  to  be  made 
is  explained,  as  are  its  relevance  and  importance,  and  the  analyst  is  given 
a  list  of  possible  answers  that  will  direct  the  analyst  to  further 
decisions  and  actions.  ACTION  nodes  aid  the  price  analyst  in  performing 
appropriate  actions.  Typically,  the  DECISION  nodes  are  at  the  top  of  the 
XINFO  net,  while  the  ACTION  nodes  are  toward  the  bottom  of  the  tree. 
However,  actions  can  also  occur  during  intermediary  stages  in  the 
processing.  Since  decisions  and  actions  often  go  together,  we  designed 
joint  DECISION/ACTION  node  that  direct  the  user  to  perform  a  given  action 
and  then  make  another  decision.  See  Figure  4  for  the  format  of  these 
nodes . 
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DECXS ION /ACTION  Nodes: 

Node  (Subaode)  Format:  ACTION  (if  any) 

DECISION  (if  any)  -  question 
OPTIONS  (if  any)  -  answers 

Options:  TES/NO  -  direct  you  to  next  decision  or  review 

NOT  SURE  -  elaboration  of  question  (PS-net) 

DON'T  KNOW  -  elaboration  of  subject  area  (L-net) 


DECISION  Nodes: 

Node  Names:  Check  <major  decision> 

-asks  the  general  (major)  questions 

Subn<>de  Names:  C<major  decision  abbr.># 

-aska  specific  questions 

Subnode  types:  -  no  present  action,  no  previous  action 

A  -  present  action 

B  -  no  present  action,  previous  action 


REVIEW  Nodes : 

Node  Names:  Review  <major  decision> 

-reviews  the  major  decision 

ACTION  Nodes: 

Node  Names:  <major  action>  Action 


Figure  4:  XINFO  Conventions 


4.2.3  Current  Implementation 

The  current  implementation  of  the  PAT  (for  £rice  Analysis  Tutorial) 
network  in  XINFO  consists  of  competitive  pricing  and  published  price 
(Appendix  II  shows  the  complete  network).  Because  of  XINFO  limitations, 
adding  the  prior  quote  method  (that  we  have  investigated  to  some  extent) 
was  not  feasible.  We  have  therefore  decided  to  move  our  implementation 
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over  froB  XINFO  to  ZOG .  This  redesign  is  discussed  later. 


4.3  An  Alternate  Model  for  Price  Analysis 

Price  analysis  is  performed  in  two  phases  as  shovn  in  Figure  5  (this 
figure  nay  be  compared  to  Figure  2).  The  first  phase,  the  Contract 
Selection  phase,  is  a  thinning-out  step  prior  to  a  Preliminary  Negotiation 
step  that  we  do  not  show  in  this  figure.  In  the  contract  selection  phase, 
Che  PA  determines  which  offers  adequately  neet  the  technical,  pricing, 
legal,  and  other  non-comparative  specifications  of  the  solicitation.  Those 
offers  that  do  not  adequately  meet  the  specifications  are  dealt  with 
appropriately  as  discussed  earlier.  After  thinning  out  the  list  of  offers, 
the  PA  performs  the  Contract  Comparison  phase  of  the  task.  This  phase  is 
the  central  price  analytic  process  performed  by  the  PA.  During  this  phase 
the  PA  decides  if  a  given  offer  is  fair  and  reasonable.  The  result  of  the 
contract  comparison  phase  is  used  in  a  Final  Negotiations  phase  (not  shown 
in  this  figure)  in  which  the  buyer  and  the  contractor  negotiate  a  final, 
agreed  price  for  the  contract.  It  should  be  apparent  from  this  description 
that  the  buyer's  price  analysis  is  performed  in  the  global  context  of 
procurement  (that  is,  at  the  contract  negotiation  level). 


4.3.1  Contract  Selection  Phase 

The  contract  selection  phase  is  a  thinning  out  process  in  which  the  PA 
checks  certain  criteria.  Each  offer  must  satisfy  both  the  technical  and 
pricing  specifications  of  the  solicitation.  Also,  the  offerer  must  not 
have  been  disqualified  (or  blacklisted)  for  some  reason  (say,  for  a  legal 
offense).  Determining  whether  or  not  an  offer  meets  the  technical 
requirements  of  the  solicitation  requires  the  aid  of  a  number  of  technical 
specialists  (Engineering  experts),  while  determining  whether  or  not  an 
offer  meets  the  pricing  requirements  of  the  solicitation  requires  the  aid 
of  other  technical  specialists  (Accounting  experts).  Those  offers  that  do 
not  satisfy  the  technical  requirements  and/or  are  not  priced  responsive  to 
the  solicitation  are  dealt  with  appropriately  (as  described  earlier). 


I  'll"  «  -  •-  V V  .  '  .  • 


-  .»  •  r. 


.V  ■  Ti  .-V  . 


V  /. 


Expert  Systems  foi 


Price  I 

Analysis  I 


I 


— . — ■ - 1 

Contract  ! 

1  Contract 

Selection  1 

l 

1  Comparison 

1  -  - 

i-  -  -i 

1  Competitive  1 

1  1 

i  i  i 

!  Published  1  | 

i  Price  1  I 

i  _ii 

-  -  -  i 

Secondary  I 
Comparisons  1 

_  *  __  I 

I  Delphi 

1  Methods 

1  _ 

-  independence 

-  more  than  1 

-  exceptions? 

i  1 . 1  1 

-  regulated 

-  catalog  or 
market? 

1  ’  1  T  “  1 

1 

! 

1 

1 

1-  ^  J""‘  "L 

1  ,  1  1  1 

1 

Prior  Quotes  1 

1 

- 1 

iCost  Estimating! 

1  Relationships  | 

1 - 1 

1  1 

!  Government  1 
1  Estimates  1 

1  Value 

I  Analysis 

1  - 

Figure  5:  Alternate  Model  of  the  Price  Analysis  Task 


4.3.2  Contract  Comparison  Phase 

During  the  contract  comparison  phase  the  PA  must  determine  if  the  lowest 
submitted  offer  that  passed  the  contract  selection  phase  was  fair  and 
reasonable.  If  the  price  is  not  fair  and  reasonable,  it  must  be  reported 
for  use  during  the  final  negotiations. 

The  contract  comparison  phase  is  similar  to  the  comparison  phase 
discussed  in  the  first  model  of  price  analysis.  Contracts  are  compared  to 
determine  a  fair  and  reasonable  price.  The  methods  to  be  used  differ  in 
their  complexity,  and  is  largely  determined  by  the  quality  and  quantity  of 
data  available.  The  primary  comparison  technique  is  Competitive  Pricing. 
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The  next  comparison  technique  is  conperison  to  Published  Prices.  The  lest 
two  comparison  techniques,  Secondary  Comparisons  and  Delphi  Methods,  are 
more  complex  techniques.  The  PA  should  use  the  easiest  method  that  is 
applicable  to  the  contract. 

Competitive  pricing  is  the  preferred  method.  The  PA  must  check  if  the 
offers  were  submitted  independently.  If  not,  those  offers  that  were  not 
submitted  independently  must  be  removed  from  consideration.  If  the  removal 
of  these  offers  results  in  the  elimination  of  all  but  one  offer,  then 
competitive  pricing  is  not  applicable  and  the  PA  should  attempt  to  compare 
the  offer  to  published  prices.  If,  on  the  other  hand,  there  exist  at  least 
two  offers,  then  the  PA  chooses  the  lowest  offer  unless  an  exception 
exists.  These  are  the  same  exceptions  that  were  described  earlier  in 
section  4.1.1.  One  of  the  "sole- source"  comparison  techniques  (Published 
Price,  Secondary  Comparisons,  and  Delphi  Methods)  must  be  used  whenever 
competition  does  not  exist.  These  comparison  techniques  are  the  same  as 
described  in  the  earlier  model  for  price  analysis  presented  in  section  4.1. 

4.4  The  Price  Analysis  Tutorial  in  ZOG 

ZOG  is  a  computer  information  system  that  is  like  XIHFO  in  that  it 
organizes  information  into  nets  and  subnets  (generally  called  ZOGnets). 

Its  capabilities  include  a  better  organization  of  information  for  display 
and  the  ability  to  invoke  and  interact  with  other  programs  and  other  jobs 
on  the  computer  system  through  the  menu-selection  mechanism.  This  "active" 
capability  makes  ZOG  more  suitable  than  XINFO  as  a  vehicle  for  an 
increasingly  "intelligent"  system. 

PAT  (Price  Analysis  Tutorial)  is  a  computer  aid  for  contract  pricing 
implemented  in  ZOG  (See  Appendix  III  for  further  discussion  of  the  ZOG 
system).  PAT  is  intended  to  guide  price  analysts  (or  buyers  operating  in 
the  capacity  of  a  price  analyst)  in  analyzing  contracts.  The  user  (the  PA) 
navigates  through  a  series  of  frames  at  which  the  user  must  make  decisions, 
take  actions,  and  is  given  the  opportunity  to  learn  more  about  performing 
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price  analysis.  FAT  contains  four  types  of  frames:  DECISION,  ACTION, 
REVIEW,  and  DOCUMENT  frames.  These  are  discussed  now. 

4.4.1  DECISION  and  ACTXOH  frames 

Moat  of  the  frames  in  PAT  consists  of  DECISION  and  ACTION  frames  as 
shown  in  Figures  6  and  7.  These  frames  contain  five  sections:  Title, 

Text,  Options,  PAT  pads,**  and  global  pads.  The  Title  is  a  one  or  two  word 
description  of  the  contents  of  the  frame.  The  Global  Pads  of  the  DECISION 
and  ACTION  frames  are  universal  ZOG  commands  that  can  be  used  for  help  on 
ZOG,  editing,  branching  to  other  locations  in  the  ZOG-net,  etc.  They  are 
briefly  discussed  in  Appendix  III. 


Pricing  Specifications  Pat27 

Each  solicitation  has  specific  requirements  about  the  type  of 
contract  that  is  acceptable  (e.g.,  firm  fixed  price,  cost-plus, 
etc.)  and  a  requirement  as  to  how  much  pricing  data  must  be 
given.  You  must  determine  if  each  offer  is  priced  and 
responsive  to  these  requirements. 

IS  EACH  OFFER  PRICED  AND  RESPONSIVE  TO  THE  REQUIREMENTS  OF  THE 

SOLICITATION? 


1.  Yes 

2.  No 


S.  SPECIFY  E.  EXAMPLE  L.  LEARN 

edit  help  back  next  mark  return  zog  display  user  goto  find  info 


Figure  6:  Sample  DECISION  frame 


**These  are  Local  Pads  as  described  in  Appendix  III.  However,  they  have 
been  re-named  PAT  pads  because  they  are  common  pads  in  all  of  the  DECISION 
frames  of  the  PAT  ZOG-net. 
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1  Offer  Elimination  Pat28  I 

I  I 

I  Those  offers  that  fail  to  meet  the  technical  specifications  I 

I  of  the  solicitation  must  either  be  revised  and  resubmitted  or  ! 

I  eliminated  from  consideration.  1 

I  I 

1  ELIMINATE  THOSE  OFFERS  THAT  DO  NOT  MEET  THE  TECHNICAL  I 

I  SPECIFICATIONS  OF  THE  SOLICITATION  AND  CANNOT  BE  REVISED  I 

I  AND  RESUBMITTED  I 

I  I 

I  I 

I  1 .  Continue  i 

I  I 

I  2.  Return  I 

I  I 

I  I 

I  S.  SPECIFY  E.  EXAMPLE  L.  LEARN  I 

I  I 

I  edit  help  back  next  mark  return  zog  display  user  goto  find  info  I 

| - 1 

Figure  7:  Sample  ACTION  frame 

The  text  of  each  DECISION  frame  consists  of  two  components :  TEXT  and 
DECISION.  The  TEXT  component  contains  a  few  sentences  that  describe  the 
process  that  the  PA  must  perform.  The  DECISION  component  is  a  question  at 
the  end  of  the  Text  section.  A  number  of  options  restrict  the  answers  the 
user  can  give  to  the  question.  These  options  lead  to  other  DECISION  or 
ACTION  frames. 

The  Text  of  each  ACTION  frame  consists  of  instructions  to  the  PA 
describing  the  action  to  perform.  The  Options  of  the  ACTION  frame  allow 
the  PA  to  continue  oh  through  PAT  or  to  return  to  the  previous  DECISION 
frame. 

The  PAT  pads  are  three  options  that  exist  in  every  DECISION  and  ACTION 
frame.  The  nS"  pad  is  available  to  the  user  who  desires  an  elaboration  of 
the  decision  or  action  of  the  current  frame  (e.g.,  an  elaboration  of  the 
decision  —  Does  this  contract  fall  into  some  exception  category?  —  would 
lead  the  user  to  frames  which  describe  the  conditions  of  each  exception) . 
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On  the  other  hand,  the  "L"  pad  leads  the  user  to  the  Learning-net  where  the 
user  can  learn  more  about  the  subject  of  the  current  frame  Ce.g.,  for  the 
same  frame  as  above  the  user  would  be  lead  to  a  portion  of  the  Learning-net 
that  explained  the  economic  theory  for  preferring  competition).  By 
selecting  the  "E"  pad,  the  user  would  be  shown  an  example  of  performing  the 
decision  or  the  action. 

4.4.2  REVIEW  and  DOCUMENT  frames 

Two  other  types  of  frames  exist  in  PAT:  REVIEW  and  DOCUMENT  frames. 
REVIEW  frames  are  entered  whenever  the  user  makes  a  positive  selection  on  a 
major  decision.  A  major  decision  is  one  that  can  be  further  elaborated 
into  a  series  of  sub-decisiona  (e.g.,  the  decision  —  Does  the  contract 
fall  into  some  exception  category?  — *  can  be  elaborated  into  3  sub¬ 
decisions,  one  for  each  exception  category).  A  positive  selection  to  a 
major  decision  is  one  that  supports  the  current  hypothesis.  (Here  the 
hypothesis  is  that  Competitive  Pricing  should  be  the  method  of  analysis  and 
the  answer  —  NO  —  is  a  positive  selection).  A  negative  selection,  on  the 
other  hand,  would  be  one  that  rejects  the  current  hypothesis.  The  Text  of 
a  REVIEW  frame  consists  of  two  components.  First,  the  criteria  that  have 
been  assumed  to  be  met  as  a  result  of  the  positive  selection  in  the 
previous  frame  are  displayed.  Secondly,  the  user  is  asked  to  confirm  the 
previous  decision.  The  user  has  two  Potions  —  to  continue  with  the  same 
hypothesis  or  to  begin  a  new  hypothesis  after  documenting  the  failure  of 
the  current  one. 

This  documentation  of  rejected  hypotheses  is  performed  in  a  DOCUMENT 
13 

frame.  These  frames  allow  the  user  to  submit  text  that  will  appear  on  the 


12 

Deciding  between  competitive  pricing  or  published  price  methods  is 
accomplished  by  checking  the  set  of  criteria  discussed  esrlier. 

^DOCUMENT  frames  can  also  be  reached  from  DECISION  frames  on  a  negative 
selection. 
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official  report  that  explains  why  the  current  hypothesis  (method)  is  not 
applicable  and  then  directs  the  user  to  a  new  frame  where  a  new  hypotheses 
(method)  is  tested. 

4.4.3  Corrent  Implementation 

The  current  implementation  of  PAT  contains  the  first  phase  of  the  price 
analysis  task,  the  contract  selection  phase,  and  the  first  two  comparison 
techniques,  competitive  pricing  and  published  price,  of  the  contract 
comparison  phase. ^  Whether  or  not  a  contract  can  be  analyzed  using 
competitive  pricing  is  determined  by  asking  a  number  of  questions.  This 
exists  in  PAT  as  a  network  of  DECISION  and  ACTION  frames  that  guide  the 
Price  Analyst  to  the  ACTION  frame  where  the  competitive  pricing  action 
("take  the  lowest  bid")  is  applied  or  to  network  of  DECISION  and  ACTION 
frames  for  published  price  comparisons. 


*^It  should  be  noted  that  although  PAT  in  ZOG  contains  some  components  iu 
comao n  with  PAT  in  XINFO,  it  differs  in  that  it  is  being  designed  with  the 
alternate  model  just  discussed. 
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5.  EDUCATIONAL  ASPECTS  OF  CONTRACT  PRICING 

Pries  Analyses  are  developed  within  the  Air  Force  via  a  system  of  both 
on-the-job  training  and  formal  education.  We  looked  at  educational  and 
other  supportive  materials  provided  to  prospective  buyers  and  price 
analysts  (and  other  personnel  involved  in  procurement).  Based  on  the 
considerations  discussed  earlier,  we  concentrated  on  materials  intended  for 
lower  levels  of  procurement  —  in  particular,  base-level  buyers  who  must 
perform  price  analysis  without  the  aid  of  a  trained  price  analyst. 

5.1  The  Current  Educational  Setup 

The  basic  buyer  support  mechanisms  are: 

-  Defense  Acquisition  Regulations  and  associated  manuals  for 
procurement . 

-  Courses  in  price  analysis  at  the  Air  Force  Institute  of 
Technology  and  at  Lowry  Air  Force  Base. 

-  Computer  programs  in  COPPER  IMPACT. 

5.1.1  Manuals  for  Price  Analysis 

The  bible  of  price  analysts  is  the  Armed  Services  Procurement  Manual, 
Number  1  (generally  called  A5PM-1  [3]).  This  manual  discusses  in  clear 
language  and  at  a  detailed  level,  the  issues  an  analyst  must  consider  when 
analyzing  an  offer.  ASPM-1  is  a  comprehensive  document  and  discusses  both 
cost  and  price  analysis.  As  a  result,  it  concentrates  largely  on  cost 
analysis  and  is  oriented  to  price  analysts.  This  makes  it  difficult  for  a 
buyer  to  acquire  the  knowledge  in  ASPM-1  and  understand  how  to  apply  that 
knowledge. 

Recently,  the  Air  Force  has  produced  a  "Guide  for  Base-level  Pricing" 
that  provides  more  specific  guidance  for  base  level  buyers.  This  document 
provides  a  buyer  with  explicit  decision  making  procedures.  It  focuses  on 
procedural  matters  and  does  not  explain  some  complex  concepts  in  price 
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analysis  well.  For  example,  the  guide  does  not  explain  what  is  to  be  done 
if  collusion  between  two  offerers  is  discovered.  The  buyer  can  solve  a  few 
pricing  problems  by  blindly  following  the  guide,  but  more  complex  problems 
would  cause  difficulties. 

Other  manuals  include  AFCMD  regulation  70-8  that  discusses  the  functions 
of  price  analysts  in  Systems  Command.  This  is  not  a  base-level  function, 
so  we  do  not  discuss  this  manual  further. 

Principles  of  Contract  Pricing  is  a  text  used  for  the  price  analysis 
course  at  AFIT  and  provides  a  fairly  complete  and  readable  presentation  of 
the  skills  needed  by  someone  doing  price  analysis.  As  with  ASPM-1,  it 
concentrates  on  cost  analysis,  but  does  not  neglect  price  analysis. 

5.1*2  Courses  for  Buyers  and  Price  Analysts 

We  were  provided  with  the  syllabi  for  two  courses  taught  at  the  Air 
Force  Institute  of  Technology  School  of  Systems  and  Logistics  that  cover 
base  level  contract  pricing.  These  courses  were  "Principles  of  Contract 
Pricing"  and  "Quantitative  Techniques  for  Cost  and  Price  Analysis."  The 
first  course  is  an  introduction  that  teaches  the  rudiments  of  price 
analysis  and  cost  analysis.  The  course  follows  the  text.  Principles  of 
Contract  Pricing.  It  is  an  adequate  course,  given  the  current  level  of 
technical  sophistication  available  to  the  analyst.  The  course  is  attended 
by  buyers  with  a  year  or  two  of  on-the-job  experience,  and  is  intended  to 
give  them  some  theoretical  background  for  activities  they  currently  perform 
under  supervision. 

The  second  course  is  an  advanced  course  that  acquaints  the  student  with 
the  quantitative  tools  and  programs  available  within  COPPER  IMPACT.  The 
course  covers  the  major  quantitative  methods  that  would  be  useful  in  the 
field.  Our  initial  observations  are  that  these  tools  are  seldom  utilized 
by  base  level  buyers.  Nor  is  there  a  tradition  among  base  level  buyers  of 
using  these  tools.  The  course  is  usually  taken  by  contracting  officers  and 
price  analysts  from  AFLC  and  AFSC,  rather  than  base  level  buyers.  It 
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appears  that  rough  and  ready  methods  of  approximation  (sometimes  resulting 
in  inadequately  documented  prices  for  contracts  that  are  not  "fair  and 
reasonable")  are  easier  to  apply.  The  tools  also  require  specialized 
training,  are  not  well  documented,  and  are  not  user-engineered;  using  them 
and  learning  to  use  them  can  be  time-consuming  and  tedious .  This  might 
imply  that  continuing  assistance  and  education  (over  and  beyond  the  course) 
are  needed  in  the  field. 

We  were  also  provided  with  study  guides  and  workbooks  for  technical 
training  for  Central/ Systems  level  contracting.  The  same  comments  are 
appropriate  here  as  were  those  presented  for  the  Af IT  courses. 

5.1.3  COPPER  IMPACT 

Our  initial  observation  is  that  COPPER  IMPACT  is  not  utilized  to  its 
full  potential.  The  biggest  problem  appears  to  be  the  lack  of  appropriate 
documentation  of  available  programs  and  indifferent  dissemination  of 
information  about  system  capabilities.  There  is  no  effective  central 
control  for  the  programs  available  (there  is  a  central  office  for  managing 
the  COPPER  IMPACT  program  as  a  whole,  but  its  influence  is  apparently 
negligible).  Programs,  data  standards,  and  styles  of  Interaction  are 
idiosyncratic;  little  standardization  results  in  little  interactive  use. 
Duplication  of  effort  results.  Other  problems  appear  to  be:  little 
programming  assistance  in  the  field,  the  high  up-front  cost  of  learning  to 
use  Che  system,  inadequate  input  data  for  the  statistical  models,  and  the 
inapplicability  of  standard  quantitative  models  to  base  level  situations. 
Base-level  buyers  often  have  difficulty  analyzing  complex  buys  because  of 
their  inability  to  obtain  or  manage  the  necessary  high-level  information 
and  to  apply  sophisticated  analytical  techniques.  COPPER  IMPACT  could  aid 
in  this  area  if  understanding  and  accessibility  were  improved.  The  current 
system  does  not  guide  the  buyer  in  analyzing  a  contract.  It  has  no 
deductive  capabilities.  It,  therefore,  does  not  help  the  buyer  in 
analyzing  md  evaluating  more  complex  buys. 
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For  COPPER  IMPACT  to  succeed,  its  capabilities  should  be  studied  right 
from  the  first  introductory  course  for  procurement  and  price  analysis.  The 
students  should  become  acquainted  with  computer-aided  procurement  and  price 
analysis  early  in  the  training  process.  This  interaction  should  be 
reinforced  when  they  return  to  the  field  to  perform  their  responsibilities. 
These  requirements  hold  true  for  any  computer-aided  system  for  price 
ana lysis. 


5.2  A  Proposal  for  Improwing  the  Educational  System 

A  buyer  goes  to  a  price  analysis  course  and  returns  t.o  the  base;  then, 
the  buyer  faces  the  problem  of  integrating  this  new  knowledge  into  a  daily 
schedule  of  activities.  How  much  time  this  takes  and  how  well  this 
integration  is  done  depends  on  how  many  times  the  buyer  has  done  the  task 
before  and  after  training.  We  propose  here  the  development  of  an 
intelligent  manual  for  contract  pricing  that  will  support  the  buyer  in 
analyzing  offers.  Such  a  system  has  a  number  of  roles  in  the  continuing 
education  of  buyers  and  price  analysts. 


1 .  Training  related  usage 


a.  Before  Training:  A  buyer  without  formal  training  in  price 
analysis  can  be  guided  through  a  variety  of  simple 
decisions  that  do  not  rely  on  a  deep  knowledge  of 
regulations.  The  system  can  also  help  the  untrained  buyer 
identify  situations  in  which  the  buyer  should  ask  for 
assistance  from  trained  personnel. 

b.  After  Training:  A  buyer  who  has  received  formal  training 
will  find  the  guidance  provided  by  the  intelligent  manual 
useful  as  a  refresher.  This  is  especially  useful  in  the 
initial  period  after  training  (when  the  buyer  may  still  be 
unsure  of  the  acquired  knowledge)  and  for  the  occasional 
unusual  case  that  the  buyer  runs  across.  Also,  the  system 
provides  a  centralized  mechanism  to  update  all  buyers 
concerning  new  regulations  that  affect  old  ways  of  doing 
the  task. 

c.  Purine  Training:  An  intelligent  manual  can  act  as  a 
computer-assisted  training/educational  tool.  During  a 
course  the  buyer  can  be  trained  to  use  this  tool  in  more 
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sophisticated  ways,  as  well  as  to  use  the  tool  for  the 
basic  task. 

2.  Interaction  with  other  systems 

a.  With  COPPER  IMPACT  programs;  An  intelligent  manual  can 
act  as  a  transparent,  knowledge-based,  supportive 
interface  to  COPPEB  IMPACT  programs  (ZOG  is  an  example  of 
such  an  interface).  For  example,  the  intelligent  manual 
could  be  used  to  obtain  data  for  some  COPPEB  IMPACT 
program  in  an  appropriate  way  from  the  user  and  use  it  to 
run  that  program  and  other  programs  to  get  the  necessary 
result.  Over  a  period  of  time,  such  a  system  could  be 
"optimized"  to  perform  routine  tasks  automatically. 

b.  With  other  systems  (for  example,  centralized  data  bases): 

Just  as  the  intelligent  manual  can  interact  transparently 
with  COPPEB  IMPACT  programs,  it  can  interact  with  other 
systems  and  present  the  information  to  the  buyer/analyst 
in  the  appropriate  fashion. 

3.  For  System  Integration:  In  the  long  run,  all  the  programs  and 
systems  that  a  buyer/analyst  might  use  should  be  available  as  an 
integrated  set  of  systems.  An  intelligent  manual  it  a  viable 
progressive  step  in  that  direction.  The  style  of  interaction 
provided  by  the  intelligent  manual  and  the  ways  in  which  it  will 
interface  with  other  systems  will  encourage  the  development  and 
enhancement  of  the  capabilities  of  the  manual  by  users  of  the 
system  theswelves.  If  this  enhancement  is  managed 
appropriately,  it  will  encourage  system  integration. 

The  intelligent  manual  approach  is  of  use  at  the  higher  levels  (Central 
and  Systems  Command)  of  performance  of  price/cost  analysis  as  well.  In 
particular,  as  the  systems  developed  for  the  lower  levels  of  analysis 
become  more  integrated,  they  will  be  of  increasing  use  for  the  higher 
levels  as  well.  Also,  some  of  the  current  human  interface  problems  faced 
by  cost/price  analysts  in  dealing  with  the  data  and  information  they  are 
given  may  be  better  handled  using  the  intelligent  manual  approach.  Changes 
in  regulations  affect  the  performance  at  these  levels  of  cost  analysis  more 
significantly  than  at  the  base-level  —  an  intelligent  manual  would  bring 
such  changes  to  the  attention  of  the  price  analyst  under  relevant 
conditions. 
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6.  SUMMARY  AND  FUTURE  ACTIVITIES 

V*  briefly  summarize  Che  future  actions  required  to  bring  the  study  to  a 
successful  conclusion. 

Our  continued  survey  of  the  pricing  environnent  will  be  based  on  the 
following  information: 

1.  Sample  contracts  and  other  contract  documents  that  provide 
examples  of  the  actual  documentation  received  and  processed  by  a 
price  analyst, 

2.  Educational  materials  used  by  the  Air  Force  in  training  price 
analysts  and  others  doing  comparable  tasks. 

3 .  Documentation  and  access  to  computer  programs  and  systems  used 
by  price  analysts  (e.g..  COPPER  IMPACT). 

The  primery  task  during  this  phase  of  the  study  has  been  to  organize, 
codify  and  analyze  the  above  information  and  to  evaluate  the  current  system 
for  contract  pricing.  Based  on  the  educational  documents  and  interviews 
with  educational  and  operational  personnel,  we  have  constructed  a 
preliminary  model  for  contract  pricing.  We  have  recommended  the  use  of 
computer-based  intelligent  manuals  to  enhance  the  current  educational 
process . 

As  discussed  throughout  this  technical  report,  a  model  of  price  analysis 
has  been  formulated  and  the  resulting  prototype  intelligent  manual  is  under 
construction.  What  is  needed  is  to  compare  the  model  with  actual  behavior. 
Also,  we  are  studying  the  problem  of  integrating  COPPER  IMPACT  programs 
with  the  prototype  implementation  in  ZOG. 

Portions  of  the  prototype  system  are  currently  in  place.  We  plan  to 
continue  to  develop  and  refine  this  system.  We  have  currently  passed 
through  one  iteration  of  the  system  and  are  in  our  second  iteration  using  a 
different  underlying  system  (ZOG)  with  better  capabilities  for  interacting 
with  other  systems  like  COPPER  IMPACT. 
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I.  INTERVIEWS  CARRIED  OUT  DURING  PHASE  I  AND  PHASE  II 

Four  separate  interview  trips  were  undertaken  during  Phase  I  and  Phase 
II  in  accordance  with  the  contract  requirements.  The  purpose  of  these 
interviews  was  to  gain  insight  in  the  methodological  approach  used  by  Air 
Force  price  analysts  in  performing  cost/price  analysis  of  contract 
proposals.  In-depth  interviews  were  undertaken  in  most  instances.  These 
sessions  provided  insight  into  the  rules  and  experience  used  by  Air  Force 
price  analyets.  Eech  of  the  four  trips  are  summarized  in  this  appendix. 

AFIT  PRICING  GROUP,  WPAFB,  DAYTON,  OHIO.  11/23/82 

Meetings  were  held  with  AFIT  price  analysis  instructors:  Mr.  Jeff 
Danesun,  Maj.  Matthew  Shields  and  others.  We  were  introduced  to  the 
learning  objectives  of  several  price  analysis  courses,  the  instructors' 
perception  of  the  contracting  environment,  and  to  the  COPPER  IMPACT  system. 
The  morning  cession  was  devoted  to  fact  finding.  The  contract  evaluation 
process  was  explained  to  the  research  group  —  the  discussion  was 
interactive,  with  members  of  the  research  group  asking  questions  of  the 
AFIT  personnel.  The  following  areas  were  discussed: 

1.  Base  level  procurement. 

2.  Coamand- level  procurement. 

3.  Major  categories  of  procurement  — ■  construction,  material  items, 
service,  and  RAD. 

4.  Parametric  estimators. 

The  afternoon  session  was  devoted  to  COPPER  IMPACT.  Two  potentially 
useful  items  were  identified:  the  PPS  program  and  the  set  of  learning  curve 
programs.  The  PPS  program  can  be  used  for  building  WBS  trees  and  for 
viewing  a  contract's  cost  structure  at  different  levels  of  details.  The 
learning  curve  programs  are  basically  curve-fitting  and  slope-estimating 
programs . 
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AIK  FORCE  LOGISTICS  COMMAND,  UFAFB,  DAYTON,  OHIO,  20  JAN  1983 

We  met  vith  Mr.  Bob  Hill,  an  expert  price  analyst  assigned  to  the  ALC 
support  staff  and  Mr.  Steve  Stitzel,  his  assistant.  The  objective  of  the 
meeting  vas  to  gather  data  concerning  the  price  analysis  function  at  both 
the  central  and  base  level,  to  determine  the  behavior  of  an  expert  price 
analyst  in  certain  pricing  situations  and  to  make  arrangements  for 
gathering  case  material.  An  interview  format  was  used  where  the  members  of 
the  research  team  asked  questions  of  the  pricing  experts.  The  following 
issues  were  covered: 

1.  Major  problems  faced  by  price  analysts. 

2.  Characteristics  of  given  sets  of  dollar  level  buys. 

3.  Current  data  available  to  the  buyer,  and  the  buyers'  propensity, 
and  capability,  for  accessing  the  data.  This  includes 
procedural  guidelines  as  well  as  operational  information. 

4.  Sources  of  data  used  by  the  analyst. 

5.  The  decisions  that  are  required  to  be  made  by  the  buyer  or  price 
analyst  during  a  contract  analysis. 

6.  The  degree,  if  any,  of  contractor  type  specialization  by 
analyst . 

7.  The  use  of  price  indices. 

8.  The  capabilities  and  utilization  on  COFFER  IMPACT. 

9.  Comparisons  of  central  and  base-level  activities  along  the  above 
dimensions . 

CM)  APPRO  SUPPORT  GROUP,  RUTLAND  AFB,  ALBUQUERQUE,  NEW  MEXICO 

24  AND  25  JANUARY  1983 

Two  days  of  intensive  interview  sessions  and  briefings  were  undertaken 
vith  the  following  members  of  the  CMD  APPRO  support  group:  Mr.  William 
Chamberlain,  Mr.  Jeff  Gardner,  Mr.  Wayne  Gaede,  Mr.  Bob  Gibson.  The  visit 
vas  to  acquaint  the  research  group  with  the  buying  activities  and 
capabilities  of  Systems  Command.  An  interactive  interview  format  vas  used. 
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The  following  objectives  were  addressed: 


1*  Level  of  sophistication  in  analyzing  contracts  and  the 
capabilities  available. 

2.  Degree  of  access  to  access  to  contractor  specific  information 
and  how  this  information  is  used. 

3.  Available  computer  systems  (e.g.,  COPPER  IMPACT  and  others)  and 
their  utilization  by  analysts. 

4.  Determine  the  interrelationship,  if  any,  betveen  APSC,  AFLC,  and 
base  level  procurement;  determine  the  applicability  of 
procedures  and  evaluate  the  possibilities  for  the  transfer  of 
technology  across  these  areas. 

5.  Gain  a  better  understanding  of  overhead  rates,  their  impact  on  a 
contract  analysis,  the  appropriateness,  and  procedures,  for 
negotiated  rates  and  methods  for  estimating  them. 

6.  APSC  support  requirements  that  might  be  addressed  by  an 
intelligent  system. 

7.  Investigate  and  understand  specific  costing  procedures:  grass¬ 
roots,  parametric  estimators,  formula  pricing,  standard  setting, 
and  historical  costing. 

8.  Identify  AP  programs  designed  to  improve  productivity  and  that 
would  have  an  impact  on  contract  pricing. 

9.  Task  based  estimation  and  contractor  cost  model  based 
estimation. 

10.  Questions  asked  by  the  APSC  price  analyst  in  analyzing  a 
contract . 

11.  The  analyst's  function  in  the  price  negotiation  process. 

12.  Development  of  cost  estimation  relationships  and  an 
understanding  of  how  they  are,  or  could  be,  used. 

13.  An  understanding  of  the  computerized  cost  model  system  in  use  at 
APCMD  and  the  knowledge  required  to  implement  it. 

14.  An  introduction  to  the  generalized  data  base  model  for  factors 
and  rates  currently  under  development. 
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AIK  FORCE  LOGISTICS  COMMAHD,  WPAFB,  APRIL,  1983 

We  met  vith  Mr.  Rollie  McReynolds  at  OSU.  The  objectives  of  the  meeting 

were: 

1.  A  detailed  discussion  of  pricing  cases. 

2.  Assistance  as  to  the  items  needed  in  the  case  packets. 

3.  An  expert's  reactions  and  evaluations  to  a  portion  of  the 
prototype  computer  system. 

Two  interview  protocols  were  used.  First,  Mr.  McReynolds  was  asked  to 
review  and  analyze  approximately  ten  case-packets.  These  sessions  were 
taped.  He  was  requested  to  "think  aloud"  during  this  process.  The 
researcher  took  an  active  part  in  the  session  by  asking  questions  about  the 
procedures  used  by  a  buyer,  the  representativeness  on  the  case,  and  the 
additional  documentation  needed.  The  cases  were  cost  analysis  cases  and 
PHMs  from  pricing  cases.  The  cases  were  evaluated  as  inadequate  for 
collecting  detailed  protocol  of  buyers'  behavior.  Mr.  McReynolds  was  able 
to  provide  valuable  information  by  generating  scenarios  based  on  his 
experience.  He  identified  the  supporting  data  that  would  probably  have 
been  used,  or  would  have  been  needed,  and  the  processes  used  by  the  buyer 
in  analyzing  the  contract. 

During  the  second  session,  Mr.  McReynolds  evaluated  the  prototype  system 
that  has  been  implemented  (in  XINFO)  up  to  that  point.  The  system  was 
explained  and  Mr.  McReynolds  went  through  the  system  to  criticise  and 
evaluate  the  usability  of  the  system  by  an  expert  price  analyst. 
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IZ.  TEE  XXH70  SYSTEM 

II. 1  The  XIH70  System:  A  Brief  Introduction 

XINFO  is  database  of  information  organized  as  a  network  of  nodes.  The 
user  of  the  XINFO  system  views  the  contents  of  this  database  by  moving 
through  the  network  from  one  node  to  another.  The  information  contained  in 
these  nodes  can  be  arbitrarily  long.  However,  by  convention  the 
information  contained  in  each  node  is  small  enough  so  that  it  can  be 
displayed  on  a  single  screen.  Each  node  contains  a  node-name  (that  is 
unique)  which  is  used  to  reference  the  node,  a  menu  containing  other  node- 
names,  and  a  set  of  a  designated  nodes  that  may  be  easily  referenced. 

Movement  through  the  X INFO- network  can  be  performed  by  either  selecting 
one  of  the  nodes  listed  in  the  menu  or  by  referring  to  one  of  the 
designated  nodes.  When  selecting  a  node  from  the  menu  list  you  may  either 
type  in  the  node-name  listed  or  type  a  number  that  represents  this  nodes 
place  in  the  menu  (i.e.,  the  third  node  in  the  list  may  be  reached  by 
typing  2,).  Designated  nodes  are  shown  at  the  top  of  each  node  (e.g.,  the 
Previous  node.  Up.  node,  Down  Node,  Next  node,  etc.)  and  can  be  reached  by 
simply  typing  the  first  letter  of  its  type  (i.e.,  if  the  Next  node  is 
"Document  Exception,"  then  "Document  Exception”  can  be  reached  by  typing 
N). 


Earlier  it  was  mentioned  that  there  was  no  restriction  on  the  amount  of 
information  that  could  be  contained  in  a  node,  but  that  by  convention  the 
information  contained  in  a  node  was  small  enough  so  as  to  allow  the  entire 
node  to  be  displayed  on  one  screen.  However,  if  it  becomes  essential  to 
use  more  than  one  full  screen  to  display  the  node  then  two  other  XINFO 
commands  are  necessary.  When  this  is  the  case,  the  user  is  given  as  much 
information  as  would  fit  on  one  full  screen  and  a  message  indicating  that 
there  is  "MORE"  is  displayed  at  the  bottom  of  the  screen.  The  user  may  see 
the  next  full  screen  by  hitting  the  <space>  bar;  the  user  return  to  the 
portion  previously  viewed  by  typing  the  letter  "B". 
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XINFO  imposes  no  set  format  for  the  information  that  is  contained  in  the 
node.  Some  rules  are  that  the  menu  items  must  follow  the  keyword:  "* 
Menu:"  and  be  on  separate  lines.  Each  item  is  preceded  by  a  and 
followed  by  a  the  nodes  in  FAT  follow  some  conventions  the  format  of 

which  was  discussed  in  Chapter  3  of  this  report. 

II .2  The  XINFO- Pricing  Guide:  Example  and  Discussion 

The  following  documented  example  gives  a  sample  of  the  use  of  PAT.  The 
user  has  been  given  3  proposals  for  a  solicitation  and  asked  to  analyze 
them  and  select  one  that  is  the  most  "fair  and  reasonable." 

The  user  initially  enters  PAT  by  typing  the  appropriate  command  to  the 
monitor  (on  our  system  that  command  is  "XINFO").  The  root  node  of  the 
XINFO  system  is  displayed  (we  do  not  show  this  node  as  it  is  not  relevant 
to  PAT).  The  user  then  types  "G"  (the  "go  to"  command)  and  specifies  the 
PAT  subsystem  by  typing  "(<PRICING>DIR)PAT".  The  top  node  of  PAT  is  then 
displayed  (see  Figure  8).  Note  that  XINFO  has  left  the  last  line  typed  by 
the  user  near  the  bottom  of  the  screen.  Also  note  (in  subsequent  displays) 
that  the  selections  are  echoed  on  the  bottom  line  of  every  node. 

In  this  example,  the  buyer  determines  that  the  lowest  offer  out  of  three 
offers  that  have  been  made  is  not  competitive  as  the  buyer  had  a  "lock"  on 
competition.  Since  there  is  a  market  for  the  item,  the  buyer  documents  in 
the  PNM  that  the  situation  was  not  competitive  and  that  the  comparison  to 
published  price  technique  would  be  used  to  evaluate  this  low  offer.  Our 
example  stops  at  this  point. 
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012.  Soda:  FAX,  Op:  ,  Previous: 

Thu  it  t  Friea  Analysis  Tutorial.  Ton  will  b«  lud  through  a  series  of 
DSCZ3I0S/ACZI0S  sodas  is  which  you  will  (possibly)  be  (iru  a  ut  of  action a 
to  partoni  and  than  (possibly)  ba  given  a  quaation  to  anawar.  Tba  basic  idaa 
of  this  tutorial  is  to  balp  teach  you  tba  cask  of  analysing  a  contract  and 
dacaraining  if  it  ia  fair  and  raaaonabla. 

is  rsx.  price  or  tu  camucr  rm  an  uasohasle? 

*  Sana: 


*  Raviaw  Fair  A  Raaaonabla::  (1)  TES 

*  Oocunaat  Fair  i  Raaaonabla::  (2)  SO 

*  Method::  (3)  SOT  SOU 

IDO  do  ■  ■  inn t ion  raadar  Soda  (OSX:<FRICZSC>DIR)  FAX 
Co  to  Soda  ( <pricia(>dir )pat 
3 


Tba  ZXnO-uaar  baa  cbraa  offara  for  tha  aolicitation. 
Obwiooaly,  aha  is  uaabla  to  anawar  whathar  or  not  tba 
tba  contract  La  fair  and  raaaonabla  without  further 
inwaacicatios  and  therefore  aba  aalaets  3  -  SOT  SOU. 


Figure  8:  PAT  node 


DIR  Soda:  Hatbod,  Op:  .  Previous: 

Tba  firac  stags  of  analysing  a  contract  involves  tba  datersinatiou  of  tba 
appropriate  aatbnri  to  uaa.  Tba  Air  Fores  baa  sat  down  a  a arias  of  guidelines 
to  follow  that  daterniaa  which  of  thasa  is  appropriate. 


vaizca  METROS  IS  affiopriaxst 


•  Check  Conpatitive: : 

•  Check  Published  Fries:: 

•  Secondary  Conpariaona : : 


•  Wild  Suasa : : 


(1)  COMPRUim  or  SOT  SOU 

(2)  F0SL1S1RD  PRICS 

(3)  PRIOR  QUOTES,  CEX  SODS LS,  SOVEEBKZbT  ESTIMATES 
sad  7AL0I  HALTS  IS 

(A)  SOU  AFFLT 


mo  damn  ant  at  ion  raadar  Soda  (DSX:  <FRICIBODIX)  Method 
31 


Tba  uaar  knows  that  tha  contractors  each  gave  published 
prices,  but  knows  that  Published  Fries  ia  only  uaad  on 
"solwaourea"  contracts.  Being  unsure  vbsc  to  do,  aha 
aalaets  1  -  SOT  SOU. 

Figure  9:  Method  node 
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DU  Sedas  Check  Competitive,  Dp:  ■  Previous: 

SC  Chip  point ,  n  sunt  decide  upon  which  sathod  Co  uaa  co  analyse  the 
contract.  If  wo  have  a  competitive  situation,  than  wa  simply  aceapc  cha 
bid  unless  Cha  particular  solicitation  falls  into  sons  EXCEPT 10 H  cacafory. 

do  vx  sun  a  ccomnm  sirnsrioa: 


*  Review  Comps ti tie a: : 

(1) 

TXS 

•  Doctmarc  Competitive:: 

(23 

SO 

*  CC1:: 

(3) 

HOT  STOZ 

QfO  docaMtttaeion  raadar  Soda  (DSK:  CPXICIHODIX)  Chock  Competitive 
313 


Sha  daairaa  an  alaboracion  on  cha  criteria  involved 
ia  datwi  ai  v  ha  char  or  not  cha  ticuacion  ia 

cc-jpatitira.  Sha  sa  laces  3. 


Figure  10:  Check  Competitive  aode 


DU  Soda:  CC1,  Dp:  ,  Pravioua: 

St  this  point,  n  oust  dacida  vtaachar  tha  offara  naac  cha  technical 
•pacifications,  Jmong  tha  iaauaa  to  ha  considered  are  what  differences 
arise  batman  tha  r squired  specif  ications  and  cha  proposed  specif  icationa, 
and  whether  tha  diffaraaeaa  ara  critical.  Tha  uains  agency  is  cha 
appropriate  jodfa  of  this. 

doss  Bscs  orra  ssnsrr  tse  trqDiuxnm  or  tsi  soticnsriosT 


•  Hams: 

«  CC2 : : 

(1) 

TZS 

•  CC2S: : 

(2) 

HO 

*  L-nat:: 

(3) 

SOT  SOU 

9TC  documentation  reader  Soda  CDSS: CJSICUODIX)  CC1 
3132 


Sf Car  close  evaluation  of  tha  second  offer,  cha  user 
determines  that  cha  offarar  tc cosily  submit cad  a 
proposal  Chat  does  not  conform  eo  the  technical 
specif Icationa  of  cha  solicitation.  Sha  selects 
2  -  *0. 


Figure  11:  CC1  node 


Anru»n/4  i  ▼ 


TT-4 
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8H  Mil  CC2A,  Up:  ,  hirlgn: 

Ton  auc  aliaiaaca  tboaa  offara  that  da  not  itciafy  da  ragaifanta  of  tha 
wlitltMia. 

Iwk  aolicitatioa  baa  apaaifie  rapui - —  about  tha  eypa  of  contract  chat 

la  acaapcabla  (a.*.,  fixa  find  prica,  coat-pluat  ace.)  and  a  muiraant  a a 
to  hov  oach  pricing  data  out  b«  circa.  Too  aaac  dacaraiaa  if  aach  of  far  ia 
ia  pricad  and  raapoaaira  to  chaaa  raqoiraaotai 

sis  ua  or  ns  inume  omu  mao  sis  usnssin  to  m  uqozuuin 

of  ns  soucxxaiiob? 


•  cast:  <i)  ru 

•  COS: :  (2)  BO 

•  L-oot::  (3)  SOI  SOU 

OH  docaoaatacioa  reader  Soda  (SiE:<nXCXK>OXS}  CC2S 

3  mi 


Zha  oaor  ia  circa  aa  aeeiaa  to  ba  parforaad  (aliaiaaca 
cha  aacoad  of far).  Tha  saar  aalaota  1  -  YXS. 


Figure  12:  CC2A  node 


DIE  Soda:  CC3I,  Up:  ,  Prarioua: 

Ooa  aajor  problaa  that  ariaaa  ia  that  cha  bida  ara  really  not*  part a 
Independently.  Too  ahoold  aaka  erery  actaapc  to  (oar ant  aa  that  thin  iodaad 
ia  not  cha  caaa.  for  iaataaaa,  aftaa  tha  only  offara  ara  actually  aada  fro* 
diffaraat  diriaioua  of  cha  aaea  company . 

on  ns  unaac  ixm  avraxu  uwuuiiuai  awn  ros  ns  cosmcrr 


•  CC4B:: 

(1) 

m 

•  CC4h:: 

(2) 

BO 

*  L-uat:: 

(3) 

BOT  son 

□DO  dacaaaatatioa  raadar  Soda  (SIX:  CTSICXSOOIS)  CC3S 
313211 


Tha  oaar  aalaota  1  -  TXS. 


Figure  13:  CC3B  node 
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OXX  Soda:  CCiB,  Up:  ,  Proviso*: 

Sow  ••  com  to  tha  aosc  important  qaaation  oacaaaary  for  che  determination 
of  vbatbtr  or  sot  tha  aitootioo  i*  competitive  or  not. 

m  am  a  least  2  ibxaihuc  szspobszslb  omuut 


*  Exception:: 

*  Chech  Pobliohad  Pries:: 

*  L-oat : : 

910  docaaaatati  nn  roador 

3132111 


(1) 

TBS 

(2) 

SO 

(3) 

SOT  SOU 

Soda  (DSX:<PSICZSC>D£X)  CCA1 


Jaa  aalacco  1  -  TO . 


Figure  14:  CC4B  node 


DIE  Soda:  Eacapcioa,  Op:  ,  Proviso* : 

Thera  appear*  to  bo  a  competitive  aitaation.  Too  should  accapt  tbo  lava  at 
off  or  unlea*  this  of  far  fall*  into  aoaa  EXCXPTIO*  catagory. 

boss  an  soucxxmos  nu  nro  son  exczptios  caizconrr 


*  Dooaanc  exception : : 

*  levies  Excaption:: 

*  EC1: : 


(1} 

TBS 

<2) 

SO 

(3) 

SOT  SOBS 

me  docaeantaeion  roadar  Soda  (DSX:<PElCISC>Dlt)  Exception 
31321112 


Sba  aalacta  2  -  SO  bacauaa  aba  knows  what  tbs  axcaptiona 
are  and  doaa  not  require  far char  elaboration.  This 
direct  a  bar  to  a  EBVZV  node. 


Figure  IS:  Exception  node 
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9X1  Soda:  Clack  Published  Price,  Up:  ,  Previous: 

AC  tkia  paint,  aa  aut  determine  if  the  eoncrccc  price  is  a  CATALOG,  HAIXZT, 
or  lICTUTm  C31Z  ST  LAB)  prica.  Ia  all  of  ekaae  cue*,  price  are  aec  by 
forcaa  beyond  the  direct  control  of  aa  indie ideal  firm. 

boss  to  comicxoi  jwrxn  ns  costiact  pxici  as  a  market,  caialoc.  as  a 
smupa  mcxT 

•  Mena: 

•  deck  Market  A  Catalog::  (1)  TXS  (MARKET  Ok  CATkT-nc  PUCK) 

•  kagalatad  Action::  (2)  TSS  (PECULATED  PlICk) 

•  Secondary  Comparisons : :  (3)  SO 

•  Wl::  (A)  SOT  SOI 


□DO  docaaaatatloa  reader  Rode  (DSX:<PKICXBC>DIK)  Clack  Publish 
31321112211 


Ha  near  kaoao  that  a  catalog  price  eaiata  for  tkia 
offer  and  therefor*  aalacta  1  -  TSS  (MASKED . 


Figure  18:  Check  Published  Price  uode 


OH  Soda:  Clack  Markat  A  Catalog,  Op:  ,  Previous: 

By  cl  lining  that  tka  price  for  tlo'  itna  ia  catalog  or  aarkat,  yon  are  laying 
chat  tha  folloniag  circa  criteria  are  aatiafiad: 

(1)  Tin  iten  ia  a  "eomaarcial  item" 

(2)  that  ia  aald  to  tka  "tenoral  pnblic” 

(3)  ia  "anbefeefial  quantities " 

Boa,  yon  Met  determine  which  of  thaaa  two  pricac  exist .  An  established 
catalog  price  ia  oaa  iaeladad  ia  a  catalog,  prica  list,  or  otkar  format  that 
ia  regularly  aaiataiaad  by  a  aaaaf securer  or  vendor .  The  prica  aaceriel  is 
either  pabliahad  or  otherwise  available  fox  inspection  by  customers .  Price 
listed  arc  tka  prices  at  which  selaa  are  currently  or  ware  list  aada  to  a 
significant  somber  of  bnyars,  including  the  seaaral  pnblic.  A  aarkat  price  ia 
a  prica  current ly  established  in  tka  usual  and  ordinary  course  of  trade 
bacwoaa  buyers  and  sellers  frsa  to  bargain.  Tha  pries  oust  ba  established 
from  sour  css  independent  of  tka  aaaaf securer  ox  vendor. 

(Kit  tha  space  bar  for  your  next  question. ) 


OTO  doesmantatioa  reader  lode  (DSK:<n2CXK>DXt)  Clack  Market  — MO l* — 
31321112211 


Tha  user  desire*  to  sou  tha  bottom  half  of  tka 
coda,  so  aha  hits  tlo  <apaca  bar>. 

Figurs  19:  Check  Market  and  Catalog  Price  node  —  top  half 
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our  it  tzx  MTtmmw  nictT 


•  Catalog  Aotioa:: 

•  Marhac  Aaeioai : 


a)  amae 

(2) 


(lie  '1'  to  root  cha  dafioicion  of  cktu  etna) 


ocioa  raadar 


Vo4a  (BS:<niCZW>oa)  Chock  Harkae 


31321112211 


Boca  that  chit  aoda  it  loagor  than  cha  root.  Za  face, 
it  ia  too  loag  to  fit  oa  oaa  ocraoa  tad  tkarafora  tha 
war  wat  kit  tka  «yaea  bar>  la  ordar  eo  taa  cha 
baccoa  half  of  tha  tor tat  tad  kit  tha  O  kaj»  to 
taa  tha  tog  half  agaia.  At  chit  point ,  oar  aoar 
talacto  1  -  CATALOG  ACTIOt  tad  U  dirtetod  to  t 
ttmiaai  aada  ia  tha  oat  ohara  tha  it  iaoenctad 
oa  bar  fiaal  aatioa  of  tha  eaak. 

Figure  20:  Check  Market  and  Catalog  Price  node  —  bottom  half 
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III.  THE  ZOG  SYSTEM 

III. I  The  ZOG  System:  A  Brief  Introduction 

ZOG  ia  a  large  databaae  (potentially  very  large)  of  information 
organized  aa  a  network  of  frames.  A  ZOG-uaer  move*  from  frame  to  frame 
uaing  the  computer  terminal  to  view  the  contenta  of  one  frame  at  a  time. 
Frames  are  deaigned  to  be  displayed  on  a  single  screen-;  by  convention, 
every  frame  has  a  one- line  Title  at  the  top  of  the  screen,  a  few  lines  of 
Teat  below  the  title,  a  set  of  numbered  (or  lettered)  menu  items  of  text 
called  Selections,  and  a  line  of  ZOG  commands  called  global  pads  at  the 
bottom  of  the  screen.  Selections  are  divided  into  Potions  and  Local  Pads 
—  options  are  usually  numbered  ("1.  ..«",  "2.  etc.),  while  local 

pads  are  usually  lettered  (MA.  . ..",  "X.  etc.).  Functionally, 

options  lead  to  other  frames,  while  local  pads  provide  the  user  with 
locally  defined  c Osmunds  (though  this  is  only  a  convention,  not  a  rule 
enforced  by  ZOG). 

Frames  are  interconnected  by  the  selections.  When  the  user  selects  an 
item  (by  typing  its  number  or  letter,  or  in  more  advanced  systems  by 
touching  the  screen  location  of  the  item),  ZOG  ^oves"  the  user  to  the 
frame  "pointed  to"  by  the  selection.  This  new  frame  is  now  displayed  on 
the  screen,  replacing  the  frame  from  which  the  selection  was  made.  The  new 
frame  will  have  the  same  general  format;  it  will  usually  contain  new 
information  and  further  selections  that  lead  to  more  detailed  information. 
Occasionally  there  may  be  "dead-ends"  —  frames  that  have  no  selections. 
Basically,  the  frame  network  is  a  hierarchical  information  structure  with 
extensive  cross-referencing  as  well  as  mechanisms  for  moving  directly  from 
frames  deep  down  in  the  hierarchy  to  frames  much  higher  up.  The  network  of 
frames  is  often  termed  a  ZOG net. 

Figure  21  shows  an  example  ZOG  frame.  This  frame  called  Estimate!  (see 
the  upper  right  hand  corner  of  the  frame  for  the  Frame- Id) .  is  the  initial 
frame  for  a  ZOG net  that  was  used  for  estimating  the  cost  of  a  new  building 
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for  the  Minina  Department.  There  are  lettered  selections  P.  and  I.  that 
identify  the  project  by  Project  and  Identifying  number,  a  set  of  numbered 
selections  that  point  to  frames  giving  further  information  (and  provide  a 
brief  summary  as  well);  there  are  more  lettered  selections  D.  N.  S.  R.  H 
that  provide  further  information  appropriate  to  the  global  level  of  cost 
estimation  implied  by  the  contents  of  this  frame.  The  global  pads  at  the 
bottom  fall  into  three  groups  —  the  set  edit,  help,  back,  display  help  the 
user  move  around  the  ZOG  system  (e.g.,  back  vill  always  move  to  the 
previous  frame  seen  by  the  user);  the  set  root,  next,  orev.  last,  new,  old 
help  the  user  move  in  special  ways  around  this  particular  ZOGnet  (e.g.,  old 
will  take  the  user  to  a  previous,  saved  estimate  for  this  building);  the 
set  print,  specs,  fill,  chk  allow  the  user  apply  certain  functions  to  this 
frame  (e.g.,  fill  will  prompt  the  user  to  fill  up  blank  spaces  in 
selections  of  this  frame).  These  global  pads  are  invoked  by  typing  the 
first  character  of  the  name  of  the  global  pad  (e.g.,  £  for  the  fill  global 
pad). 

| - 1 

I  Estimating  System:  Level  0  Building  Estimatel  I 

I  ?.  Project  Name:  Mining  Department  (Filled  in  by  Estimator)  I 

I  I 

I  I.  Project  ID:  DM- 501  I 

I  I 

I  1.  Location:  (address)  ■ 

I  I 

I  2.  Building  Type:  _ __  I 

I  I 

I  3.  Direct  Estimated  Value:  Sxxxxx  Range:  $xxxxx  to  $xxxxx  I 

I  I 

I  4.  Aggregated  Estimate:  Sxxxxx  Range:  Sxxxxx  to  Sxxxxx  I 

I  I 

!  D.  Documentation  S.  Specifications  H.  History  I 

I  N.  Supporting  Notes  R.  Risk  Assessment  i 


edit  help  back  display  root  next  prev  last  new  old  print  fill  chk 
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III. 2  The  ZOG- Pricing  Golds:  Example  and  Discussion 

The  ZOG-basad  pricing  guide  is  intended  to  guide  the  user  (a  buyer  or 
price  analyst)  through  a  series  of  questions  that  must  be  raised  in  a 
procurement  situation.  If  the  user  cannot  ansver  a  particular  question, 
the  system  will  simplify  the  question  into  simpler  questions;  at  the  lowest 
level  (at  the  level  of  primitive  concepts)  the  user  may  obtain  background 
knowledge  of  the  subject  dosuin  by  directing  oneself  to  the  tutorial 
section  of  the  ZOG-net  (the  Learning-net)  that  teaches  the  necessary 
concepts  or  to  another  section  that  provides  the  user  with  examples. 


Pricing  Specifications  Pat27 

Each  solicitation  has  specific  requirements  about  the  type  of 
contract  that  is  acceptable  (e.g.,  firm  fixed  price,  cost-plus, 
etc.)  and  a  requirement  as  to  how  much  pricing  data  must  be 
given.  You  must  determine  if  each  offer  is  priced  and  responsive 
to  these  requirements. 

IS  EACH  OFFER  PRICED  AMD  RESPONSIVE  TO  THE  REQUIREMENTS  OP  THE 
SOLICITATION? 

1.  Yes 

2.  No 

S.  SPECIFY  E.  EXAMPLE  L.  LEARN 

edit  help  back  next  mark  return  zog  display  user  goto  find  info 


Figure  22:  PAT27  —  A  decision  frame 


The  are  four  types  of  frames  in  the  ZOG-based  pricing  guide:  DECISION 
(see  Figures  22,  23,  and  25),  ACTION  (see  Figure  24),  REVIEW  (see  Figure 
26),  and  DOCUMENT  frames  (see  Figure  27).  The  user  begins  in  a  DECISION 
frame.  At  this  frame  the  user  has  the  option  of  answering  the  question 
shown  (for  example,  in  Figure  23  the  question  is  "What  is  the  appropriate 
method?")  by  selecting  one  of  the  options  on  the  menu  (in  Figure  23,  the 
options  are  "1.  Competitive  Pricing”  to  ”4.  None  Apply")  or  typing  S. 
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Figure  23:  PAT29  —  A  Deciaiou  Frame 

(i.e,  "please  specify  or  elaborate  on  the  question  being  asked").  In  the 
frame  of  Figure  23,  typing  S,  would  send  the  user  to  the  frame  that  checks 
if  competitive  pricing  is  appropriate,  while  selecting  one  of  the  options 
would  lead  to  a  frame  that  checks  if  the  selected  method  is  appropriate.*^ 
All  of  the  possible  selections  from  this  frame  lead  to  other  DECISION 
frames.  However,  this  is  not  always  the  case.  From  the  frame  shown  in 
Figure  22,  the  user  will  reach  another  DECISION  frame  by  selecting  option  1. 
or  the  ACTION  frame  shown  in  Figure  24  by  selecting  option  1. 

The  ZOG-net  has  been  created  by  connecting  a  series  of  major  DECISION 
frames  together  with  minor  DECISION  frames  and  ACTION  frames  between  them 


*^Hotice  that  typing  i  and  S.  leads  the  user  to  the  same  frame. 
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i _ i 


I  Competitive  Pricing  Pat32 

I 

I  At  this  point,  we  must  decide  upon  which  method  to  use  to 
I  analyze  the  contract.  If  we  have  a  competitive  situation, 

I  then  we  simply  accept  the  proposal  unless  the  particular 
I  solicitation  falls  into  some  EXCEPTION  category. 

I 

I  DO  HE  HAVE  A  COMPETITIVE  SITUATION? 

I 
I 

I  1 .  Tea 

I 

I  2.  No 

I 
I 

I  S.  SPECIFY  E.  EXAMPLE  L.  LEARN 

I 

I  edit  help  back  next  mark  return  zog  display  user  goto  find  info 

I - - - 

Figure  23:  PAT32  —  A  Decision  Frame 
for  elaborating  the  major  questions  and  necessary  actions,  respectively. 
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I  Review  Competitive  PAT33  I 

I  I 

I  By  claiming  that  a  competitive  situation  exists,  you  are  I 

!  claiming  that:  I 

I  I 

I  (1)  At  least  2  responsible  offerers  responded  to  the  solicitation  and! 

I  passed  the  Contract  Selection  Phase.  I 

I  (2)  The  offerers  independently  contended  for  the  contract.  I 

I  I 

I  I 

I  1.  Continue  I 

I  I 

I  2.  Document  (not  a  competitive  situation)  I 

I  I 

I  I 

1  S.  SPECIFY  E.  EXAMPLE  L.  LEARN  I 

I  I 

I  edit  help  back  next  mark  return  zog  display  user  goto  find  info  I 

Figure  26:  PAT33  —  A  Review  Frame 

| - 1 

I  Document  Competitive  Pat34  I 

I  '  I 

I  Enter  text  documenting  your  reasoning  for  not  being  able  to  I 

I  use  Competitive  Pricing  on  this  solicitation.  I 

I  <You  can  do  this  by  typing  the  "D  Pad">  I 

I  I 

I  I 

I  1 .  Continue  I 

I  I 

I  2.  Review  (is  a  competitive  situation)  I 

I  I 

I  I 

I  D.  DOCUMENT  I 

I  ! 

I  I 

I  S.  SPECIFY  E.  EXAMPLE  L.  LEARN  I 

I  I 

I  edit  help  back  next  mark  return  zog  display  user  goto  find  info  I 

| - 1 

Figure  27:  PAT3  4  —  A  Document  Frame 

The  other  two  types  of  frames,  viz.  REVIEW  and  DOCUMENT  frames,  also  exist 
between  major  DECISION  frames.  REVIEW  frames  are  entered  whenever  a  major 
decision  is  answered  positively  with  respect  to  the  current  hypothesis.  A 
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positive  response  to  the  hypothesis  supports  its  appropriateness .  For 
example,  in  the  frame  shovn  in  Figure  25  the  answer  "yes,  it  is  a 
competitive  situation"  is  a  positive  response  to  the  hypotheses 
"competitive  pricing  analysis  methods  may  be  used”.  By  selecting  option  1. 
the  user  is  directed  to  the  REVIEW  frame  shown  in  Figure  26.  DOCUMENT 
frames,  on  the  other  hand,  are  reached  whenever  the  user  gives  a  negative 
response.  Such  a  frame  allows  the  user  to  document  the  rejection  of  a 

current  hypothesis  and  directs  the  user  to  a  DECISION  frame  where  a  new 

hypothesis  can  be  tested.  For  example,  from  the  frame  shown  in  Figure  25, 
the  user  will  be  lead  to  the  frame  shown  in  Figure  27  by  selecting  1. 

Eventually,  the  uaer  of  the  ZOG-Pricing  Guide  will  be  directed  to  a 
terminal  ACTION  node  from  which  there  are  no  selections  or  paths  to  other 
frames  in  the  Pricing  subnet  of  ZOG.  When  this  point  is  reached,  the  uaer 
will  have  analyzed  the  offers  for  the  solicitation,  determined  which  one 
will  receive  the  proposal  (if  more  than  one  existed),  and  completed  the  PNM 

(Price  Negotiation  Memorandum)  for  the  contract.  Now  the  award  can  be 

made!  Such  a  terminal  frame  also  provides  facilities  for  documenting  the 
action  taken. 
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